Consensus on the kdelibs coding style

[Alexander Neundorf]

On Saturday 05 July 2008, Thiago Macieira wrote:
> Lubos Lunak wrote:
> >which defines even completely useless things like
> >requiring {}'s around a single-line if() body statement (where's the
> > point in that?), I'd prefer something simple.
>
> Just for information, that requirement is not in the Qt style. That's
> actually one of modifications that was added to the KDE Libs style on top
> of the Qt style. If you look at Qt code, you'll see that is not used.
>
> Anyways, regarding your proposal, I'll say what most other people will
> say: I disagree in certain points, but having one *single* style is
> better than having none, whatever the style is (as long as it makes
> sense, of course).
>
> The major point is actually deciding on the "4 spaces, NO TABS"
> (capitalisation mine, but should be there). Tabs are inherently evil and
> should be banned altogether, to the point of warranting a wide-reaching
> tab-replacement commit (svn can now ignore whitespace changes in
> annotation, git has been able to do it for years).

In cmake and I guess most other Kitware projects you cannot commit patches 
which contain tabs, so this makes very sure that this rule is followed.
We could do that too if we *really* want to.

> A distant second is the placement of the braces. Your style is closer to
> my own preferred style, actually, but I'd still advocate for matching
> Qt's simply because of pragmatism.
>
> The only thing I don't like in your code is the indentation of label-like
> constructs (case labels and public/protected/private) because of this:
>
> class Foo
> {
>     Foo();
>     public:
>         Foo( int a );
> };


IMO here the problem is a missing recommendation:
always use the order public - protected - private (with a note about signals 
an slots), and never to rely on the default protection in classes.

(but we didn't want to make the coding style too complex).

Alex