line lengths

[Imported from Trac: page CodingStandards, version 20]

CodingStandards.md

@@ -37,7 +37,7 @@ from allmydata.util.assertutil import _assert, precondition, postcondition
  * Put one blank line before a block comment if the preceding line is code at the same indent level (this makes it harder to mistake the code as part of the comment, and makes the comment easier to read). 
  * Feel free to ignore the part of PEP-8 that says to put each module import on a separate line, but don't import modules from multiple separate packages on the same line.
  * Ignore the part of PEP-257 which says to put the trailing `"""` of a multi-line docstring on a separate line separated by a blank line.  (That rule appears to have been motivated by a limitation of Emacs which has been fixed.)
- * Ignore the part of PEP-8 which specifes 79- or 72- char line widths. We use 77 columns. In emacs set `fill-column` to 77 (e.g. `M-x set-variable fill-column 77`).
+ * Ignore the part of PEP-8 which specifes 79- or 72- char line widths. Lines should preferably be less than 100 columns, but we don't enforce this strictly. It is more important to break lines at points that are natural for readability than to follow a fixed line width restriction. Where possible, continuation lines should be indented as far as necessary to make them match up with the subexpression (e.g. argument list) they belong to.
  * PEP 8 says: "If operators with different priorities are used, consider adding whitespace around the operators with the lowest priority(ies)." This is a good rule; note that it also applies to some non-obvious low-priority operators, like '`:`' for list slicing. (Example: `a[: d]b-c` good, `a[- c:d]b` bad. If a slice is from the start or to the end of the array, put the '`:`' immediately next to the bracket on that side.)
 
 ### truths and falsehoods