I think having longer lines of code hurts readability. There is lots of typographic evidence to back this up ( e.g. http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/. Of course, the typographic commentary applies to text rather than code, and most text isn't indented, but I still think it's right). Even where the "monitors are wider than they are tall" argument goes, I prefer to use that space for multiple columns of text, because even if you do allow >80 char lines, most lines are shorter and hence you have a lot of wasted space.
Granted, it is a combination of factors. I come from a C-based lineage of 2-space indentation, short variable names, and <8-character function names. Those all combine to make an 80- character line length workable. People who come from a 4-space (or greater) indentation, and the long variable-names style of Java or C++-with-templates will tend to see things differently. -- Dirk On Fri, Apr 16, 2010 at 3:09 PM, David Levin <le...@chromium.org> wrote: > (I have contributed but not often.) I also agree with " 80 columns hurts > readability." > It doesn't take much looking to show a lot of lines that demonstrate this. > However, I understand the desire to just take PEP8 whole. Once you decide to > throw away one item, why not argue about any other.... (I tend to think 80 > columns is the only thing that should be thrown out.) > Sincerely, > dc86ed7c29395f2b0863967f5350dfca4151be9d > On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak <m...@apple.com> wrote: >> >> On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote: >> >>> <bike-shedding> >>> >>> I think 80 columns is a waste of time and hurts readability. >>> >>> Instead of being smart about when we wrap code, 80 adheres to a >>> blanket rule, discourages long variable/function names, and needlessly >>> expands code vertically ignoring modern wider-than-long monitors. >>> >>> The optparse code which was recently re-wrapped is one example of 80c >>> fail. Impossible to tell in the wrapped version which arguments are >>> actually being listed (first argument to the function) because your >>> eye can't parse the start of each line. >>> >>> That said. I'd rather have you and Adam and Chris all working on the >>> Python than have folks lose interest due to code wrapping. If the >>> consensus is 80c, I'll learn to deal. :) >>> >>> The choice is either: >>> A. no wrapping rule to match the rest of WebKit >>> B. 80c to match the official PEP8 spec (and Google code). >>> >>> I've chosen A. in the past. Mostly to match my own personal bias I'm >>> sure. >> >> I haven't contributed to WebKit's Python code yet, but I will say that I >> agree with Eric's sentiments here. 80-column limit is archaic and pointless. >> No one is developing WebKit on a vt220. >> >> Regards, >> Maciej >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev