Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: David Palao <dpalao.python@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Guido sees the light: PEP 8 updated
Date: Mon, 18 Apr 2016 13:35:42 +0200
Lines: 108
Message-ID: <mailman.147.1460979350.6324.python-list@python.org>
References: <5711c1b3$0$1596$c3e8da3$5496439d@news.astraweb.com> <dne6huFi9sfU1@mid.individual.net> <87shym6kpo.fsf@elektro.pacujo.net> <CAPTjJmrq-pFDGS14PE+FXx=B+fXBD-Pkqc9JdQrjULR9aXRSxg@mail.gmail.com> <mailman.43.1460795561.6324.python-list@python.org> <87h9f26ioa.fsf@elektro.pacujo.net> <1460809922.1918014.580580553.0AE05EE4@webmail.messagingengine.com> <CACwCsY5EG_RFHe8DMF4VStYCsSuO-gMC+KRx05q9=vu8aa3K9g@mail.gmail.com> <mailman.50.1460818461.6324.python-list@python.org> <878u0d7az5.fsf@elektro.pacujo.net> <8ff10001-1c49-4490-b873-018507243ea3@googlegroups.com> <CAPTjJmqAN-McpPUxiBRCU75mYxhU6-4_9imvBxQRFVLERBoyFA@mail.gmail.com> <mailman.89.1460864965.6324.python-list@python.org> <04721fe6-5feb-49c8-b5b2-beb12f6ff495@googlegroups.com> <5714522d$0$1622$c3e8da3$5496439d@news.astraweb.com> <CAKUKWzmpSrhQyngRCmUKt_HJMhM83nShFFoYboZL+YjB_V8gQA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <5714522d$0$1622$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Xref: csiph.com comp.lang.python:107267

2016-04-18 5:19 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
> 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
>
> --
> https://mail.python.org/mailman/listinfo/python-list

Excellent! Thank you for this contribution.