[Development] commas in ctor-init-lists

André Somers andre at familiesomers.nl
Fri Jun 3 08:45:29 CEST 2016


Op 03/06/2016 om 08:28 schreef Martin Smith:
>> but it is very structurally clean and in some circumstances I prefer it due to that.
> The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the reader that another list item will follow. There is nothing to clean. Note the comma I used appeared right after the word "Historically,"  as did that one, and that one appeared right after the word "none."  The comma has never appeared as the first character of anything.
>> Note there is a related coding style violation for if statements.
> The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a word to the reader ( "or"). The comma doesn't represent a word.
Well, if we go that way, lists of conditions are often written like this:
You can do this, given:
* You bla, or
* You boo, or
* You foo

Note the position of the or. Does that mean that the equivalent C++ 
should look like this:
if ( bla ||
       boo ||
       foo )
{ //we can debate the position of the opening brace here as well...
     do this...

No. I think this drawing of parallels with natural language formatting 
is not very productive. Code is not natural language and we should not 
apply the same formatting rules to them.

>> This has the same benefits for diffs as the leading comma,
> Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with an option to suppress it?
Ehhh? The diff is there and is significant, isn't it? So it should not 
be suppressed unlike some stray white space differences.

Anyway, I am all for using an auto-formatter. I think they are good 
enough nowadays. They may not in every circumstance generate the 
absolute most beautiful layout, but it saves a huge amount of time not 
having to care for it anymore, not getting style^Hformatting related 
-1's from the CI any more and not having to debate it any more. So I 
think it is well worth the loss of prefered formatting here and there. 
And yes, you can use your own prefered format locally if you please, as 
long as it gets reformatted to the standard one on submission. Sounds 
ideal to me.


More information about the Development mailing list