>You can do this, given:
Nobody does that. We always write: * You bla, or you boo, or you foo, and in
this case we would normally write: You bla, you boo, or you foo. Even better:
You bla, boo, or foo. You are inventing problems that don't exist.
________________________________________
From: Development <development-bounces+martin.smith=qt...@qt-project.org> on
behalf of André Somers <an...@familiesomers.nl>
Sent: Friday, June 3, 2016 8:45:29 AM
To: development@qt-project.org
Subject: Re: [Development] commas in ctor-init-lists
Hi,
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.
André
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
