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

[Dirk Pranke]

Hi all,

As I'm sure the discussions in the webkit meeting over the past two
days made clear, it looks like most of our non-C++ code is getting
written in Python. Back in January, Adam Barth posted this thread [1]
where I thought it was agreed we would attempt to follow PEP 8 ([2] -
the standard Python style guide) faithfully.

The one (somewhat) controversial aspect of that style guide is that it
requires a 79-column wide line length.

More recently, as part of implementing a style checker for Python code
[3], some have advocated that we should not follow that particular
restriction, because (a) the WebKit C++ style guide does not follow
that restriction, and (b) there is a reasonable amount of Python code
that does not follow the rule today and would have to be brought into
compliance. In particular, it was asked that we disable the long-line
check until at least the existing code was brought into compliance.

As far as (b) goes, there are currently (as of r57510) 1533 long lines
out of the 35,616 lines found under WebKitTools/Scripts/webkitpy,
occurring in 120 out 193 .py files. Most of the files that have any
long lines have less than five [4].

As far as disabling the check goes, I rather firmly believe that if we
wish to follow an ~80 column line-length limitation, the check needs
to be on by default, or else those who aren't used to this convention
will not follow it and the problem will get worse, not better (as
evidenced by [5]).

So, do we want to follow an 80-column limit for Python code, or not,
and if we do, should we enforce the rule by default or not?

If the concern is the existing code base I also (reluctantly)
volunteer to fix the long lines, if that influences the decisions.
Although I personally believe that code that is less than 80 columns
wide is easier to read and easier to maintain for a variety of
reasons, I mostly volunteer to do this because it's just not many
lines of code and I believe that having style guidelines that aren't
followed are a Very Bad Thing and hence the fact that we have existing
violations is a bad reason in this case to argue for not following the
rule.

Note that I do not particularly wish to argue the merits of this
particular style choice, just make (and document) a decision. It's a
religious position and the interweb is littered with existing
arguments pro and con that we would likely just rehash here. I raise
the issue at all only because I had thought that we made a decision
and then it was changed in relative obscurity in a bug, rather than
after being discussed here, whch struck me as not the right way to do
this sort of thing.

-- Dirk

[1] https://lists.webkit.org/pipermail/webkit-dev/2010-January/011423.html
[2] http://www.python.org/dev/peps/pep-0008/
[3] https://bugs.webkit.org/show_bug.cgi?id=33639
[4] Stats:
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | wc -l  # 193 .py files
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs wc -l  # 35,316 lines of code
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) > 79) printf("%s:%d %s\n",
FILENAME, FNR, $0);}' # all of the long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) > 79) printf("%s\n", FILENAME);}'
| sort | uniq -c | wc -l # 120 files w/ long lines
% find WebKitTools/Scripts/webkitpy -name thirdparty -prune -o -name
\*.py | xargs awk '{ if (length($0) > 79) printf("%s\n", FILENAME);}'
| sort | uniq -c # distribution by file
[5] https://bugs.webkit.org/show_bug.cgi?id=37586