[Development] commas in ctor-init-lists

[Thiago Macieira]

On sexta-feira, 3 de junho de 2016 08:42:20 BRT Eike Ziller wrote:
> 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

Alignment of the *comma* is not important. It's a small thing, just a few 
pixels tall. It's only there because we need to have it.

What's important is the aligment of the variable names. Regardless of where 
you put the comma, the variable names will align. Therefore, I don't think the 
above is an argument.

> * easier diff when adding something at the end (which is commonly done)

True, though with intra-line and across-line diffs that Gerrit shows, this is 
minimised. It shows that the previous line was unmodified except for the comma.

> * easier rearrangement when it involves the last item

True, but same as above.

> * easier ifdef’ing of individual items

Only if it involves the last item. And since #ifdef is a sore eye anyway, 
using a sore-eye construction for the last item is not going to make it much 
worse.

Please also note that this only applies to ctors with already-split lines. 
They often don't start like that. They often have a few variables and are 
initialised like:

Foo::Foo()
	: i(0), status(None), enabled(false)
{
	// ...
}

When that grows, it becomes:

Foo::Foo()
	: QObject(*new FooPrivate), ptr(nullptr), i(0), 
	  status(None), enabled(false)
{
	// ...
}

Besides, do we need a rule so that our if-else chains with #ifdef in the 
middle be nice too? I've seen a lot of code do:

#ifdef FOO
	if (foo) {
		// something
	} else
#endif
	if (bar) {
		// something else
	} else {
		// default
	}

That if-else chain violates our coding standard. Should we adapt it so that it 
works with #if in the middle? I would prefer not.

(there's trick you can do to minimise this; exercise left to the reader)

> 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 let's insert a space *before* *every* comma!

> > 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.

Agreed.

Consistency is important for me, which is why I reject patches to QtCore that 
contain leading commas.

I only allow it if it is necessary because of #if, which already made it a 
sore-eye in the first place. That is, in QtCore, it's only allowed when 
strictly required.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center