[Python-ideas] 80 character line width vs. something wider
Stephen J. Turnbull
stephen at xemacs.org
Wed May 20 04:38:55 CEST 2009
Jason Orendorff writes:
> On Tue, May 19, 2009 at 1:15 PM, Raymond Hettinger <python at rcn.com> wrote:
> > Though I suspect your note was trolling, I agree with you and find the 80
> > character width to be an anachronism.
> I find the long lines in my code are not as contrived as the thread so
> far suggests:
I do find several of them unreadable. Brief classification:
> t = t[:m.start()] + t[m.end():] # ok because we're iterating in reverse
Plausible usage; gets the comment out of the control flow, which is good.
> sys.stderr.write("js-build: WARNING: Due to COMMAND_MODE madness, this can fail on Leopard!\n"
> "js-build: Workaround is to upgrade to Python 2.5.2 or later.\n")
Ditto, for arbitrary I/O content.
> allVariants = [_m + _r + _x for _x in ('', 'x') for _m in ('', 'm') for _r in ('r', 'd')]
I find that hard to read. With more than two clauses, I prefer to put
them on separate lines anyway:
allVariants = [_m + _r + _x for _x in ('', 'x')
for _m in ('', 'm')
for _r in ('r', 'd')]
> yield Message(parseTime(attr(u'received')), who, text(msg), isAction)
Mildly hard to read; I tend to skip the details of a complex call on
one line, and have to go back if I need them. Eg, in review I would
very like miss a typo where the 2nd and 3rd arguments are
(incorrectly) swapped unless I read that line token by token. I'm much
less likely to make that mistake for
yield Message(parseTime(attr(u'received')), who,
although I grant that at 81 characters for the long line, the two-line
format is distinctly uglier.
> while self.node is not None and self.node.nodeType == self.node.TEXT_NODE:
Unecessary for me. I would use a sentinel whose nodeType is
SENTINEL_NODE for this anyway, rather than None.
Note that there are two kinds of arguments presented. One is that the
long line isn't necessary. That obviously has to depend on higher-
level issues of style (eg, using None vs. a special nodeType as a
sentinel), so definitely YMMV, and if a lot of people in your project
prefer the None-style, that's an argument *for* long lines. The other
is that I find some hard to read, and if there are more than a very
few in your project who feel as I do, long lines can have a *negative
impact* on review.
More information about the Python-ideas