[webkit-dev] python coding style, PEP-8, and 80-column line widths

Dirk Pranke 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
greater) indentation,
and the long variable-names style of Java or C++-with-templates will
tend to see things

-- Dirk

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
> 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 <mjs at 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

More information about the webkit-dev mailing list