[Development] commas in ctor-init-lists

[Martin Smith]

>Why devious?

Because every human being learns from an early age that when forming a list of words separated by commas, each comma is placed immediately after the word. Putting the comma at the start is a deviation from what every human being first learned. No human being on the planet was taught to put a comma at the beginning of a line.

But this is not an issue of readability or feeling natural. The three formats are equally readable. One can even argue that if the list is long, the single line format is less readable than either of the multiple line formats.

Nor should the auto-indent feature of your favorite editor have any sway. My editor handles either multi-line format with ease. If yours can't, get better one.

So we really just have the conditional compilation issue and the diff noise issue. These are valid issues.

So, here is a simple Qt coding style guideline.

In a comma list, be consistent about where the comma is placed. Either place it immediately after each list item (comma-last), or at the start of each line (comma-first). When using conditional compilation in a comma-last list, change the entire list to be comma-first. Once a list becomes comma-first, never change it to comma-last, even when the conditional compilation is removed.

martin

________________________________________
From: Eike Ziller
Sent: Friday, June 3, 2016 10:42:20 AM
To: Martin Smith
Cc: Edward Welbourne; André Somers; development at qt-project.org
Subject: Re: [Development] commas in ctor-init-lists

> On Jun 3, 2016, at 10:07 AM, Martin Smith <Martin.Smith at qt.io> wrote:
>
> I think it would be instructive to hear the reasoning of the first engineer to add a ctor-init-list on separate lines with leading commas. I have been in the software engineering business since BEFORE Al Gore invented the internet, yet I have never been temped to start a line with a comma.

> What devious thinking would cause one to do that in the first place?

Why devious?

Let’s have a look at the advantages of both styles:

comma at the end:

* feels more natural wrt natural languages

comma at the start:

* better visual alignment together with the : and , all at the start
* easier diff when adding something at the end (which is commonly done)
* easier rearrangement when it involves the last item
* easier ifdef’ing of individual items

The advantages of the one are the disadvantages of the other.

So some people argue that “feels more natural” overweighs the perceived small advantages of comma at the start.
And some other people argue that coding has not much to do with natural languages anyhow, the “small” advantages are worth the change, and it doesn’t feel unnatural anymore after getting used to it.

> Then why not just add a note to the Qt coding style saying that using the leading comma is allowed|recommended when using conditional compilation in a comma list? Why does it have to be uniform throughout the entire code base? Sometimes diffs are hard to read.

Possibly because for some people consistency is of higher value.

(Disclaimer: I personally really don’t care which style is taken.)

Br, Eike

> martin
>
> ________________________________________
> From: Development <development-bounces+martin.smith=qt.io at qt-project.org> on behalf of Martin Smith <Martin.Smith at qt.io>
> Sent: Friday, June 3, 2016 10:00:26 AM
> To: Edward Welbourne; André Somers; development at qt-project.org
> Subject: Re: [Development] commas in ctor-init-lists
>
>> Please allow that,
>
> I do, of course. Andre didn't. He wrote...
>
>>> if (blah || boo || foo) {  //no line breaking allowed
>
> ...with the comment.
>
> ________________________________________
> From: Edward Welbourne
> Sent: Friday, June 3, 2016 9:54:43 AM
> To: Martin Smith; André Somers; development at qt-project.org
> Subject: Re: [Development] commas in ctor-init-lists
>
> André
>>> So that means that our C++ code should look like this then?
>>> if (blah || boo || foo) {  //no line breaking allowed
>
> Martin
>> In that case, yes, because the entire expression is short. And the
>> ctor example that was used originally would also be on one line. Why
>> not? Does the Qt coding standard require each expression to be on a
>> separate line? I thought they should be on separate lines when the
>> list is too long to be on a single line.
>
> Please allow that, in giving illustrations, short texts may be used as
> surrogates for tacitly long ones, so that
>
>  if (blah
>      || boo
>      || foo) {
>      some.code();
>  }
>
> is tacitly standing for
>
>  if (somee.really(long.and.complicated, expression)
>      || another.such(that, makes, the.line.too.long)
>      || and.then.some.more()) {
>      some.code();
>  }
>
> in examples - it gets boring to write the examples out in full like that
> and I would hope everyone is capable of interpolating the big long ugly
> expressions for which short tokens are used in illustrations.
>
>        Eddy.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
+123 45 6789012
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B