2016-04-18 5:19 GMT+02:00 Steven D'Aprano <st...@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.
--
https://mail.python.org/mailman/listinfo/python-list
