From 96b3975e7abac91522d8d064a2ea7e147f96295e Mon Sep 17 00:00:00 2001 From: Chandan Singh Date: Tue, 26 Nov 2019 19:13:05 +0000 Subject: doc/coding_guidelines: Drop section about line lengths Since we format our code using Black, contributors don't have to think about line lengths themselves. In fact, Black is going to rewrite the files anyway so it's not even possible to make a judgement call in most cases. --- doc/source/hacking/coding_guidelines.rst | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/doc/source/hacking/coding_guidelines.rst b/doc/source/hacking/coding_guidelines.rst index 4ba6360b6..ecab2410f 100644 --- a/doc/source/hacking/coding_guidelines.rst +++ b/doc/source/hacking/coding_guidelines.rst @@ -25,21 +25,6 @@ Formatting will be checked automatically when running the testsuite on CI. For details on how to format your code locally, see :ref:`formatting code `. -Line lengths -'''''''''''' -Regarding laxness on the line length in our linter settings, it should be clarified -that the line length limit is a hard limit which causes the linter to bail out -and reject commits which break the high limit - not an invitation to write exceedingly -long lines of code, comments, or API documenting docstrings. - -Code, comments and docstrings should strive to remain written for approximately 80 -or 90 character lines, where exceptions can be made when code would be less readable -when exceeding 80 or 90 characters (often this happens in conditional statements -when raising an exception, for example). Or, when comments contain a long link that -causes the given line to to exceed 80 or 90 characters, we don't want this to cause -the linter to refuse the commit. - - .. _contributing_documenting_symbols: Documenting symbols -- cgit v1.2.1