Consensus on the kdelibs coding style

Alexander Neundorf neundorf at
Sat Jul 5 22:27:17 BST 2008

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).


More information about the kde-core-devel mailing list