[Development] Resolving coding style contentions

Edward Welbourne edward.welbourne at qt.io
Mon Nov 19 11:34:09 CET 2018

On Sunday, 18 November 2018 05:30:26 PST Sze Howe Koh wrote:
>> I'd just like to know: Did the Qt Project ever reach a decision? If not,
>> how can we reach one?

(Linked to the discussion of constructor initializers like

  MyClass(type param)
    : MyBase(param)
    , myMember(param)

using comma at start of line, for anyone who hasn't followed the link.)

Thiago Macieira (18 November 2018 20:49) replied
> I don't think we did. Right now, it's up to the maintainer's discretion.

My (highly unreliable) memory concurs.

> QtCore opts into the rule: newlines are whitespace.

(I wonder if we'll ever get round to renaming that character class
"spacing characters" - I've been using blackspace in my reverse-video
emacs windows for a quarter century now; and, before that, I used quite
a lot of greenspace.  But web-browsers insist on it being white.)

> Corollary: you can only insert a newline where a space is allowed by the
> coding convention.

I note a glaring exception to that: after the opening parenthesis of
a parameter list, if the line would otherwise be too long:

  auto variable = QCharacteristicallyVerboseClassName::characteristicallyLongFunctionName(
          firstParameter, secondParameter, thirdParameter, fourthParameter);

is tolerated (well, maybe not the naming ...), but a space *without*
the line-break between open-paren and firstParameter is forbidden.

It remains that we got no consensus on the newline-comma pattern
for classes; it mixes virtues and vices.  Some maintainers will let you
do that.  Some won't.  This reviewer has mixed feelings about it.

> And since our coding conventions are that commas and semi-
> colons have no space to the left, you can't insert a newline there either.
> Exception: complex #if, as in the declaration of qCompilerCpuFeatures in
> qsimd_p.h and qsimd_x86_p.h:
> static const quint64 qCompilerCpuFeatures = 0
> #if defined __ARM_NEON__
>         | CpuFeatureNEON
> #endif
> #if defined __ARM_FEATURE_CRC32
>         | CpuFeatureCRC32
> #endif
> #if defined __mips_dsp
>         | CpuFeatureDSP
> #endif
> #if defined __mips_dspr2
>         | CpuFeatureDSPR2
> #endif
>         ;

(The "no space allowed" point is just at the end, before the semicolon.)
I see this as more an example of the one rule to rule them all:
* When strictly following a rule makes your code look bad, feel free to break it

It remains that this can apply equally justly to the newline-comma
case (at least) when the last member of the class is subject to #if-ery,

  MyClass(type param)
    : MyBase(param), myMember(param)
#if QT_CONFIG(myfeature)
    , myFeatureSpecificMember (param)

which, all things considered, is the case that I believe motivated the
newline-comma pattern among various peers I've known who liked it.


More information about the Development mailing list