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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development