Guido sees the light: PEP 8 updated

[Steven D'Aprano]

On Mon, 18 Apr 2016 11:39 am, Rustom Mody wrote:

> yes we can agree on this -- arbitrary line lengths are almost certainly
> unreadable.
> The problem then becomes so what is optimal?

I really don't think it is a problem. We have about 400 years
of experience with printed text, and that experience tells us
that the optimal width for reading prose in Western languages
is about 60 characters, give or take. This width is optimal
for eye movement, and minimizes the number of errors and 
reduces eye-strain.

There's only so far that our eyes can follow a line to the
right without increasing stress or reading errors, and 
likewise when returning back to the left margin. The longer
the line, the higher the chance of losing track, and the
physical effort it takes to read. (You have to move the eyes
further, and for extremely long lines, you may have to move
your entire head.)

Long lines are simply harder to read because you have to
move your eyes more, and the longer the lines, the greater
the tendency to wander across the lines. Especially if the
lines are close together and the height of the lines is
small. (It boggles my mind how many programmers I've met who
routinely view their code in tiny physical heights, even
when reading it in fine detail.)

The optimal width for eye-tracking (that is, the maximum
width for which the rate of such errors can be disregarded)
is somewhere about sixty characters per line.

The same eye-tracking considerations apply to code, but:

        when it comes to code, we don't always have to track all the
        way back to the left-hand margin. If we start (say) up to 
        twenty columns in, then we can afford to write up to twenty
        columns further to the right too.


(Also, code tends to have VERY ragged right-hand margins.
Not all lines end up even close to sixty characters wide.)

There are other considerations though. Unlike prose, with
code, shorter lines *may* sometimes force an increase in
complexity. For instance, temporary variables need to be
created, or new functions created, just to avoid otherwise
excessively long lines. So one might be willing to accept a
little more eye-movement for a little less code complexity.

So allowing a total width of 80 (give or take) is already a
compromise from the optimal sixty characters. This compromise
allows for indented code, and allows up to 20 characters
extra to avoid creating more complexity elsewhere.


But there's another factor: long lines of code are themselves
a code-smell. Perhaps:

- you have indented too deeply, suggesting that your function
  is doing too much or has too much internal complexity:

  def func():
      if a:
          for b in seq:
              while c:
                  with d:
                      try:
                          try:
                              for e in it:
                                  block  # only 48 columns available here

  (But note also that even with this extreme example, eight
  indentation levels deep, you can still fit almost 
  characters per line without breaking the 80-char limit.
  You can do a lot in 50 characters.)


- you have too many expressions on one line, suggesting that
  the over-all complexity of the line is excessive;

- your variable or function names are needlessly verbose or
  are doing too much or are too specific
  ("calculate_number_of_pages_and_number_of_semicolons_in_chapter_one");

- or you are violating the rule of Demeter:
  get(customer.trousers.pocket.wallet).open().money.pay(1)


In other words, long lines of code are themselves an 
indication of poorly-designed code. Even though there are 
exceptions, we should resist strongly the urge to extend
beyond the 60-80 (or perhaps 90 in extreme cases) limit.
Whenever I hear people saying that they regularly need to
use 100 or even 120 columns for their code, what I hear is
"my code is badly written".



-- 
Steven