kdelibs coding style

[Maksim Orlovich]

> With much love from Russia comes temperature checker (prediction: it's
> hot! flaming hot!) in the form of a proposal for a common coding style
> in kdelibs.

I see severe thunderstoms approaching Poland.

At any rate, I am very disappointed to see this. I always thought one of
the strengths of KDE was to let developers develop, without needless rules
forcing them all on the same page.

>
> It's something we talked about during the KDE Four meeting. The reason
> for it is that it's a pain in a butt to read through kdelibs code.

The reason against it, of course, is that some people read certain code a
lot more than the others. Quick, out of all the people who were at the
event, who was the last one to touch Keramik sources in any significant
way?

> Indention differs within files which makes a lot of them unreadable

Of course the reason it's inconsistent is that some people have attitude
that they don't have to respect the author's choice. The same attitude
that this proposal seems to share.

> To make it clear, no mass reindenting would take place.. For already
> existing code the indention would be changed when a person would be
> editting it. So if you fix a bug in already existing code, you simply
> indent your code with the standard indention. This way history won't be

Good job on thinking this through.


> Well, the only exception are libraries that are not maintained in the
> KDE SVN (for example, if it ever happens, integrated KHTML/WebKit would
> be maintained outside KDE SVN and the coding style that applies to it
> is one chosen for this project - interestingly enough WebKit coding
> style is basically exactly like Qt coding style so that's not going to
> be an issue).

Well, since you brought up Apple, let me share some of my frustrations in
dealing with them, since I think they're a a super-extreme version of what
you're proposing: yesterday, I merged some of their changes in KJS, in
about a 12,000 line diff. In that diff, I could may be point out 3 changes
that actually affected functionality, and one reasonable refactoring. The
rest consisted of moving stuff around, changing indentation, "beautifying"
things, etc.  IOW, probably 90% of the code changes were utterly useless.
I have also see them do code reviews on clearly broken patches, and
respond with 10-15 points on where the whitespace should be. I see this
proposal as a miniscule step towards the same path. Even something this
tiny is sad to see, however, when kdelibs in trunk barely works;
in other words: I would be more receptive of reports of agreements on this
at the meeting if kdelibs were able to launch klauncher more than 75% of
the time.


-Maks