[RFC] Characters per line: from punch card (80) to line printer (132)

[Martin Sebor]

On 12/5/19 8:46 AM, Thomas Schwinge wrote:
> Hi!
> 
> ;-P Jakub, thanks for furnishing me a fit occasion here:
> 
> On 2019-12-05T16:15:15+0100, Jakub Jelinek <jakub@redhat.com> wrote:
>> [...] much more indented though, but you could
>> use a temporary, like:
>> 		      tree nullarg = null_pointer_node;
> 
> I object to cluttering the code by introducing temporary variables/names
> just for the sake of a few characters of screen width.  Even if located
> close lexically, when reading the following code you still have to trace
> back from the 'nullarg' usage to its 'null_pointer_node' definition in
> order to figure out what a 'nullarg' might be:
> 
>> 		      if (present)
>> 			ptr
>> 			  = gfc_build_conditional_assign_expr (block, present,
>> 							       ptr, nullarg);

The snippet of code above looks like it might be the symptom
of another common problem: deeply nested conditionals, case
statements, or loops in very large functions.  Those usually
make it much harder to follow code than local variables or
expressions that are broken up to fit the width limit.
Shorter functions typically also means fewer local variables.

One thing I find improves readability in functions with many
local variables is declaring const those that don't change
after initialization.  That also enforces the initialization-
on-declaration coding style, and can result in more efficient
code.

Another solution that might help in this context is default
function arguments: if the last argument may be null, making
it the default in the function declaration avoids having to
pass it explicitly.

> 
>> Another option would be shorten the name of the function, say
>> s/conditional/cond/.

As long as it doesn't compromise readability this sounds like
a good suggestion for a change to the function above.  _cond_
is no less clear or descriptive than _conditional_, similarly
to _expr vs _expression.

> 
> Likewise I object to "crippling" identifier names like that just for the
> sake of a few characters of screen width.  (Here of course, "cond", or
> the existing "expr" might be fine abbreviations, but my point is about
> the general case.)
> 
>> There were some discussions about lifting the 80 column restriction and bump
>> it to something like +-130, but nothing happened yet.
> 
> Indeed.  :-)
> 
> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner
> stated that even he is not using a 80 x 24 terminal anymore, and that
> should tell us something.  ;-)
> 
> So, I formally propose that we lift this characters per line restriction
> from IBM punch card (80) to mainframe line printer (132).

I'm not a fan of rigid rules, especially those that are subject
to personal style preferences.  At the same time I wouldn't like
to see lines become as long as this as the norm.  As others,
I have windows om my desktop arranged in a way to maximize screen
real estate: three columns of editor/debugger and a couple of
terminals on of top of the other.  They only fit because they're
all 80 characters wide.  But more important:

> deep
> indentation often is a sign that code should be split out into a separate
> function, for example.

Exactly.

Martin

   My point is just to avoid things like the two
> examples cited above.
> 
> Also, I'm not proposing any mass-reformatting of the existing code, or
> re-writing all "expr" into "expression".
> 
> Tasks:
> 
>    - Discussion.
>    - Get agreement/make a decision (by means still to be determined).
>    - Put suitable Emacs/Vim configuration files into the source tree?
>    - Update coding style guidelines.
> 
> 
> Grüße
>   Thomas
>