[webkit-dev] python coding style, PEP-8, and 80-column line widths
dpranke at chromium.org
Fri Apr 16 16:12:26 PDT 2010
I think having longer lines of code hurts readability. There is lots
of typographic evidence
to back this up ( e.g.
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
and the long variable-names style of Java or C++-with-templates will
tend to see things
On Fri, Apr 16, 2010 at 3:09 PM, David Levin <levin at chromium.org> wrote:
> (I have contributed but not often.) I also agree with " 80 columns hurts
> 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.)
> On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Apr 16, 2010, at 1:48 PM, Eric Seidel wrote:
>>> 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
>> 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.
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev