[Python-ideas] 80 character line width vs. something wider

Aaron Rubin aaron.rubin at 4dtechnology.com
Thu May 21 20:01:55 CEST 2009


This thread is going where the OP didn't want it to go.  Personal preference
has already been decided to vary greatly.  Seems to be about 50/50.
 Obviously THAT won't change.  I was looking for objective arguments, not
subjective ones.  Arguing over *how* to break lines is actually a pretty
strong argument that time is wasted spent on such issues.  A longer line
width would reduce these arguments, since less would need to be wrapped.
So far, let me do a tally of objective arguments, just to keep this thing
rational:

New facts supporting 80 character line width:
1) Most conventional printers in portrait format can print 80 characters
nicely in a line.
2) New netbooks have less width on their screens, making 80 characters
nicer.  (This actually probably calls for an even narrower width if this is
a big concern)
3) If the code is standard library code, given that we have some folks out
there who still write with 80 character line widths, then that code should
still be 80 characters to fit the Least Common Denominator.
4) 2 space indentations reduce the preceding whitespace on each line by 50%,
making 80 characters more reasonable. (and obviously, if people are using 2
space indents, horizontal space was at a premium).  Also it appears from
context that Google uses 2 space indents.
5) Older editors might have trouble handling greater than 80 character
widths, including older terminal emulators.

New facts supporting greater than 80 width:
1) Comment blocks are even more limited than originally thought, especially
if following the PEP 8.
2) The standard library generally needn't leverage OO as much as code using
it (in fact, much of the stdlib is procedural in nature), thereby making the
stdlib less wide by nature.  This is true of any core library...it is
generally simpler code reused most often. Complex business logic, scientific
programming, etc. also tends to need longer variable names since these
notions can't be called simply "tool", but what type of tool and in an
environment with many "tools" this name gets longer to be more descriptive.


Other new facts:
1) Around 200 lines of code even within the standard library start at the
10th indentation level (40 characters gone already)
2) Around 10 percent of unique variable names even within the standard
library have 15 characters or more
3) The origin of 80 character limit widths came from punch cards

Of course, the original facts still remain (with original fact #7 held out
as a weaker point, but still remains the only scientific study mentioned
thusfar).

What did I leave out?

 - Aaron


On Thu, May 21, 2009 at 9:59 AM, Raymond Hettinger <python at rcn.com> wrote:

>
> [Lie Ryan]
>
>> This is how I will write program if we have 160 character limit:
>>
>> def foo(f, a, b, c):
>>    return [[((f(x, y) * i, i) if i % 2 else 0) for i, x in enumerate(a) if
>> f(y, x) == a + x] for y in [c(z) for z in range(a, a * b + c, c)]]
>>
>> except there will be no line breaks...
>>
>> I love list comprehension so much that I often _unconsciously_ write a
>> very complex list comprehensions. 80-character convention acts as a reminder
>> to consider refactoring.
>>
>
> that makes sense to because your example starts close to the left margin.
> What I'm more concerned about is lines that start many tabs deep.
> Those become awkward, causing you to wrap them differently than
> if they were not tabbed.  So, I think the 80 char limit should be relaxed
> only when there is a bunch of whitespace to the left.  Your cues for
> refactoring  and coding style should not depend on the initial level of
> indentation.
>
>
> Raymond
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20090521/e8cacc36/attachment.html>


More information about the Python-ideas mailing list