This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Dec 05, 2019 at 04:46:45PM +0100, 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);
> 
> > 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);
The above case is extreme in both being indented quite a lot (general rule
is to consider outlining something into a function then) 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.

> 
> > 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).

Such a proposal would need to be accompanied with a wwwdocs
codingconventions.html patch and contrib/check_GNU_style.{sh,py} patch I
guess ;)

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]