[Tutor] Correct style of line break when chaining methods

[dn]

On 11/07/2021 04.33, boB Stepp wrote:
> On Sat, Jul 10, 2021 at 11:20 AM boB Stepp <robertvstepp at gmail.com> wrote:
>> On Sat, Jul 10, 2021 at 11:03 AM Manprit Singh
>> <manpritsinghece at gmail.com> wrote:
>>>
>>> Dear sir,
>>>
>>> See in this particular example, the length of the line is 75 characters ,
>>> and according to PEP 8, in Python a line must not exceed 69 characters.
>>
>> Are you sure you did not misread the max recommended line length?
...

>> Limit all lines to a maximum of 79 characters.
...

> The concept of 80 characters line length is a historical artifact from
> the early punch card and terminal days.  However, 80 characters is
> often cited as "about" the right line length for humans to process
> chunks of information.  But modern software and monitors can
> substantially stretch this "about" line length to just about any
> length you find comprehensible and convenient.  And remember PEP 8 is
> a guideline only.

0 bring back punch-cards!

1 I can't remember why "79", instead of the 80-column preceding
'standard' (which also followed punched cards, even when
terminals/screens were capable of more than 24x80 - but back-then some
languages mandated the use of the first columns and perhaps also the
last). Perhaps the 80th column would be where the "\" line-continuation
character fits?

2 as someone with aged and ageing eyes, I find a narrower line easier to
read (within reason). Thus, the longer the line, the harder it is to
read. Even more-so if the screen necessitates horizontal-scrolling! NB
if I simplify the code I (could) write, in order to be considerate of
others who might follow, is it unreasonable to request 'narrow lines'
for the benefit of old fogies like me?

3 when including code within a lesson or article (conference
presentation or other slide), the margins are often considerably
narrower than (even) 79-columns. (I struck this issue whilst remotely
attending an on-line Code Review, just last week)

4 I find myself torn between coding on a wide-screen in portrait or
landscape mode (horizontal or vertical orientation). The portrait
display gives a view of more lines of code - usually am able to scan
between a function call and its definition (there's another 'rule' about
such proximity, somewhere). Contrarily, the landscape mode enables
multiple 'panes' so that I am able to read a library function/method
call on one pane and its definition in another. Thus, code-width should
be no wider than the width of my vertical screen's 'width'; and no wider
than will fit in the two or three panes that may span the width of my
horizontal screen! (and we're back to that 'magic number' of columns, or
even slightly less)

5 I notice that my (simple-text) email-client also limits line-length,
even though it is displaying the text using a variable-width font...


> I am currently using an automatic Python code formatter called
> "black".  It determines its default line length a bit longer than
> 79/80 characters (from
> https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#line-length):
> 
> <quote>
> 
> Line length
> 
> You probably noticed the peculiar default line length. Black defaults
> to 88 characters per line, which happens to be 10% over 80. This
> number was found to produce significantly shorter files than sticking
> with 80 (the most popular), or even 79 (used by the standard library).
> In general, 90-ish seems like the wise choice.
> </quote>

Black is described as "opinionated", by which they mean that their
opinion counts for more than any and all of the several and varying
opinions already stated 'here'!

Yes, that's an irony!

See also XCKD's "standards" cartoon (https://xkcd.com/927/)


> And Mats suggested the need for judgement when you are "close to"
> whatever your predetermined line length is.  Splitting lines
> unnecessarily can make the code harder to read than fudging your line
> length limit sometimes.

...and equally, splitting the line (with appropriate columnar
formatting) may make each 'unit', of a long and complex LoC, easier to
comprehend!

+1
*Human* readability trumps all!

Hobgoblins be gone...
-- 
Regards,
=dn