Consensus on the kdelibs coding style

[Michael Jansen]

> ===== 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". 

+1 . I prefer the braces to be indented. "Whitesmiths style" like i learned 
from your wikipedia page. But every style not having trailing braces is fine 
with me.

>  Plus the somewhat automatic "don't write messy code".

And that's the most important thing. I have seen perfectly styled code with 
all the braces and spaces where they belong. But it was just messy and 
unreadable/not understandable. 

> I've never really learnt to visually identify blocks with the trailing { 
> style, after all those years).

+1 

I would perhaps add:

- Max line count for methods/functions and files.
- Some preferred line lenght (80 or 120 are values i encountered). 
(Plus a warning that those values aren't hard limits. If necessary/needed it's 
ok to break them.)
- A warning to only bother other developers (especially newbies) if they 
checkin unreadable code (no comments, 300line methods, for/switch/if nested x 
deep, variable names x,y,z etc. ). Not because you miss some spaces. If you 
are convinced code get's unreadable because of one/two missing/unneeded spaces 
i assure you the problem is on your side.

And the hint if you really feel obliged to comment on someones coding style do 
it with a private email. I don't think this kind of email belongs to a mailing 
list. Most persons getting schooled that way go into defense mode 
automatically when you call them out in front of everyone.

Mike

-- 
Michael Jansen
Available for contract work ( Development / Configuration Management )
http://www.michael-jansen.biz