Consensus on the kdelibs coding style

[David Jarvie]

On Sat 5 July 2008 14:41:23 Lubos Lunak wrote:
>  Therefore I suggest we restart this exactly once more. And this time,
> preferably with something looking at least a bit like conclusion and
> getting reasonable choices. I think the current policy sucks, but what
> sucks a lot more is the way we got it - by changing agreement ([1]) about
> having a coding style ('a' style, I was there and the vote I remember
> didn't have 'Qt' anywhere in it) into having to use the Qt style without
> having a choice ([2]) and ignoring any feedback (am I the only one who sees
> the contradictions e.g. between [3] and [4]?). I was away by that time,
> missed the party and reading the whole thread later was rather an
> experience (and BTW, I read it again now, all of it, just to make sure I
> remember it correctly). Now the situation is that the Qt style is at
> techbase, marked as 'recommended but not enforced at all', which basically
> means anything, and that's how people currently handle it.

This corresponds with my understanding that there was no real conclusion, but 
somehow an "official" style was declared regardless.

> ===== Coding style proposal =====
>
>  As the numbers above show, we can still switch to anything we want, and
> there's not much sense in being overly detailed, since that will probably
> never be followed (it's not quite in the KDE spirit to be pedantic, is
> it?). Therefore I'd like to sum the policy as
>
>  "4 spaces, no tabs, {}'s column-aligned, indent everything". Plus the
> somewhat automatic "don't write messy code". Plus possibly some additional
> recommendations I find obvious for people who can't live without them, as
> non-mandatory. Plus "only major contributors to a file can reformat it".

Thinking about this again, I don't really see why there should be a 100% 
uniform coding style in kdelibs. Why is there a need for a coding style 
police to scrutinise every detail of code? I strongly agree with your 
approach that a few basic rules should be applied, and the rest should be 
optional, although I'd prefer the rest to be explicitly unspecified to avoid 
extra rules creeping in the way it has already happened. I'd propose the 
following three rules in addition to yours:

1) The original author of a file should have freedom to apply whatever style 
he/she prefers, subject to the basic kdelibs rules (as you propose).

2) Within any one source file, the coding style should be kept consistent. 
That means following the predominant coding style if there is already a mixed 
style, or for small changes following the style of the surrounding code.

3) There are no more rules.

On Sat 5 July 2008 15:13:33 Thiago Macieira wrote:
> 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.

I agree with Lubos that aligned braces make code much clearer to read. I fail 
to see the relevance of matching Qt's style - that is a completely separate 
code base, and I don't see any problem when reading code in switching between 
Qt and KDE, even if the styles are different. We all have to cope with style 
differences anyway.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm