On Thu, Dec 05, 2019 at 05:03:43PM +0000, Jonathan Wakely wrote: > On Thu, 5 Dec 2019 at 16:44, Michael Matz <m...@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
