[Development] commas in ctor-init-lists

Marc Mutz marc.mutz at kdab.com
Wed Jun 1 23:27:44 CEST 2016


On Wednesday 01 June 2016 16:33:39 Sergio Martins wrote:
> On Wednesday, 1 June 2016 15:44:22 WEST Marc Mutz wrote:
> > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote:
> > > Subjective reasons against leading commas:
> > > - It's ugly
> > > 
> > > Subjective reasons against trailling commas:
> > > - It's ugly
> > 
> > I beg your pardon? Trailing commas are ugly? So where's the text editor
> > that folds prose text to have commas on the next line?
> 
> What does prose text have to do with C++ ? When people say readable code
> resembles english it's not about punctuation. It just means you can
> understand the business logic by reading the variable and function names:
> 
> while (isSick) { eatApples(); }
> 
> You're pushing the analogy too far.

I don't think so. Semicolons and commas are visually *designed* to be 
trailing. And consequently every C++ text book uses trailing commas. Not even 
GNU style dares to tread there. Seeing leading commas just hurts visually, and 
they are not idiomatic C++. To a C++ programmer, they look alien, out of 
place.

That is not the case with whitespace, or where to put braces, because there is 
corresponding variance in the C++ text books, too. But there is no variance in 
comma placement. *All* C++ text books use trailing commas.

> > > - You can comment it out by commenting only 1 line
> > > - Code generators / tooling only have to touch 1 line to add or remove
> > 
> > All these are also valid for enums and function argument lists, but I see
> > no- one doing similar things for enums and functions.
> 
> What does function arguments have to do with ctor-init-lists ?

What do they *not* have to do with each other? They are both comma-separated, 
and often need line wrapping to fit within the given column limit. Functions 
also may have parameters that are absent in conditional compilation. Functions 
are used more often and tend to have longer expressions as arguments than 
ctor-init-list entries, making such problems as cited for ctor-init-lists more 
frequent in functions than in ctor-init-lists.

> The number
> of member variables to initialize scales linearly with the number of
> features, can you say the same about functions ?

I dispute that. A class that has more than five semantically-different data 
members smells just as strongly as a function that has five arguments.

> Do you keep growing your
> function until you have 10 or 20 arguments ? I don't care about commas in
> functions, I refactor the function instead.

And I'd refactor the class, too.

> Agreed about enums, but I write a order of magnitude more ctors than enums,
> so never felt motivated to use C++11 trailling enum feature.

Well, and we all write an order of magnitude more functions than ctors, so why 
come we never use the same comma rule as for ctor-init-lists?

We instead write the same function twice, cf. QTemporaryFile ctors vs. 
QT_NO_QOBJECT. Why? Because it's *ugly*.

NSDMI and ctor delegation will solve most of this, btw, for ctor-init-lists 
(but not functions).

It seems to me that people are arguing that a problem exists in a construct 
used X times (ctor-init-lists), and the same problem does not exist in a 
construct used 10X times (functions) per unit code.

Either be consequent about it, and demand the same (the ugly) comma placement 
for function arguments and enums, or acknowledge that the reasons cited for 
using leading commas in ctor-init-lists are applicable to functions and enums, 
too, and, seeing no problem there, are thus no problem in ctor-init-lists, 
either.

Otherwise, this is nothing more than arguing for some random, inconsistent, 
style-of-the-day, just because some Nokia-era modules happen to use it in 
violation of the Qt Coding Style, QtBase and C++ text books existing practice.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts



More information about the Development mailing list