kdelibs coding style

[Thiago Macieira]

Maks Orlovich wrote:
>Sure, but I would say nearly all of these above have clear, unambiguous
>benefits. Having someone change where the braces are in Keramik or how
> many spaces khtml/ecma is indented with doesn't.

You'll allow me to disagree. I'd say that there are clear benefits for 
readability and maintainability of code. I'd also say that indentation is 
not a deterring factor in new contributors. I'd finally say that it is 
not setting a precedent for arbitrary rules.

We know maintainers change. We know people have to touch other people's 
code. Authors are not the only people who touch their code.

We should think long term.

Now, how should we decide this? It's clear that the entire KDE community 
is not at issue here. It's also clear that it's not even all developers: 
this is kdelibs that we're talking about. 

Do you want to put this to a vote? Then we need to define who should vote.

If it's not a vote, I'd say there is a clear majority in this discussion 
favouring the proposal.

BTW, since I am the KNetwork maintainer and only author, I am imposing the 
proposed indentation style to my own existing and future code. And I 
suggest to Matthias Kretz that he do the same to Phonon too, and George 
to kwallet, etc. Maybe if we've got enough critical mass, it'll just look 
pointless to have a few files looking different from the rest. It doesn't 
have to be a top-down decision: it can be bottom-up.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060723/d1c15e29/attachment.sig>