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 <ja...@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
