This is the mail archive of the 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]

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


;-P Jakub, thanks for furnishing me a fit occasion here:

On 2019-12-05T16:15:15+0100, Jakub Jelinek <> 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.)

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

Nonwithstanding that, we should try to not overstrain that; deep
indentation often is a sign that code should be split out into a separate
function, for example.  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".


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


Attachment: signature.asc
Description: PGP signature

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