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 05:03:43PM +0000, Jonathan Wakely wrote:
> 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 ;-)

Not using such a nice feature just because of formatting sounds really
shameful.  Would the compromise of 100 chars make things any better here?

Marek


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