[Development] commas in ctor-init-lists

[Edward Welbourne]

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

yet, when the list items are too big to inline and a display list is
used, I would most certainly have
 * first thing,
 * subsequent ... things,
 * penultimate thing or
 * final thing.

with the or on the end of the penultimate entry.  Our coding style asks
for the equivalent of that "or" being on the start of the final thing.
I can even argue for why that makes a certain sense - it *is* easy to
miss that trailing "or" on the end of the penultimate item, which *can*
make it harder for the reader to tell whether this is an or-list or an
and-list.  Yet I do in fact use the style just illustrated and would
only use the other if I wanted to put particular emphasis on the "or".

However, as others have pointed out, arguing by analogy with typographic
practice in English is not really pertinent to the case in point.  This
is code; we put parentheses around things for quite different reasons
than English text does and we use commas differently, too.

André:
> So that means that our C++ code should look like this then?
>
> if (blah || boo || foo) {  //no line breaking allowed
>     something();
> }

No.  Our coding style quite explicitly says that you can split lines as
long as the operator appears at the start of the line.  I personally
find that butt-ugly; but it's what our coding style mandates so I go
along with it.  Regularity makes for ease of reading, once you are
familiar with the form being followed, as long as it's not too
perversely bad - so I tolerate that every job I've ever had has obliged
me to use a coding style I don't like.  I can think of a case where that
style was so bad it got in the way, but what we presently have as our
coding style is half-way decent and that's good enough for me.  There is
too much diversity of preference for any coding style to be blessed in
the eyes of all, so we live with a consensus all can endure.

I do, however, like the suggestion that we formalise it all into a
scriptable style that can be what the code gets mashed into on commit,
with each developer free to mash into any style they like on checkout.
Show me an implementation of that and I'll be happy to see the end of
all flame-wars about code layout.

Other than that, changing coding style just leads to inconsistency in
the code-base; even a change to a style I prefer needs a stronger
argument for it than "I prefer it" to get over the cost of the
transitional phase with some code in the old style, some in the new.
I'd sooner stick to a style I don't like but can read well enough than
have the approved style keep changing.

	Eddy.