[RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

Segher Boessenkool segher@kernel.crashing.org
Thu Dec 5 20:21:00 GMT 2019


On Thu, Dec 05, 2019 at 05:04:12PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote:
> > 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);
> > 
> > > Another option would be shorten the name of the function, say
> > > s/conditional/cond/.
> > 
> > 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.)
> 
> The point about temporaries is general, and I believe they actually make
> code much more readable.  Mostly about coding style like:
> 	t = fold_build2_loc (loc, code, fold_build2_loc (loc, code2,
> 							 something1,
> 							 something2),
> 			     fold_build2_loc (loc, code3, something3,
> 					      something4));
> vs.
> 	tree op1 = fold_build2_loc (loc, code2, something1, something2);
> 	tree op2 = fold_build2_loc (loc, code3, something3, something4);
> 	t = fold_build2_loc (loc, code, op1, op2);

Yes.  And the names, even if they do not say much, *do* say enough to
help comprehending the code.  They help structure it.

> The above case is extreme in both being indented quite a lot (general rule
> is to consider outlining something into a function then)

I hope you mean actual factoring, not just outlining :-)  If you pick good
factors you can give them good names, too.

Good names help reading the code.  And on the other hand, when it is hard
to come up with a good name for a piece of code, it is probably not chosen
as a good factor anyway!

> and using
> way too long function names.  If you look at the earlier suggestion where
> the code is indented reasonably, using the temporary there makes the code more
> readable and shorter.

Yup.


Segher



More information about the Gcc mailing list