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)

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Thu, 5 Dec 2019 at 16:44, Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> (oh a flame bait :) )
>
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>
> > So, I formally propose that we lift this characters per line restriction
> > from IBM punch card (80) to mainframe line printer (132).
> >
> > Tasks:
> >
> >   - Discussion.
>
> I object to cluttering code in excuse for using sensible function names or
> temporaries that otherwise can help clearing up code.  Using 132-char
> lines is cluttering code:
> - long lines are harder to read/grasp: vertical eye movement is easier
>   than horizontal, and source code should be optimized for
>   reading, not writing
> - long lines make it impossible to have two files next to each other at a
>   comfortable font size
> - long lines are incompatible with existing netiquette re emails, for
>   instance
>
> So, at least for me, that my terminals are 80 wide (but not x24) has
> multiple reasons, and the _least_ of it is because that's what punch cards
> had.

C++17 introduces a nice feature, with rationale similar to declaring
variables in a for-loop init-statement:

if (auto var = foo(); bar(var))

The variable is only in scope for the block where you need it, just
like a for-loop.

Unfortunately nearly every time I've tried to use this recently, I've
found it's impossible in 80 columns, e.g. this from yesterday:

    if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=>
0; __c != 0)
      return __c;

When you're forced to uglify every variable with a leading __ you run
out of characters pretty damn quickly.

I can either not use the feature (and have the variable defined in a
larger scope than it needs to be) or add fairly arbitrary line breaks:

            if (auto __c
            = __builtin_memcmp(&*__first1, &*__first2, __len)
            <=> 0; __c != 0)
              return __c;

or try to give the variables shorter (and less meaningful) names.
Adding line breaks or picking shorter names doesn't help readability.
So I end up not using the feature.

I'm loosely in favour of relaxing the rule for libstdc++ code. I don't
really care what the rest of GCC looks like ;-)