kdelibs coding style (summary attempt)

[Kevin Ottens]

Hello list,

If you read this mail I assume that you have already read Zack Rusin's mail 
and the attached style. Otherwise you'd better read it first.

This thread has grown a lot. Freedom concerns have been raised, the style 
attached to the proposal has been commented... We even got a few tricks on 
how to configure best your editor.

That's why in the following I'll try to provide a summary keeping the most 
important parts covered (sorry guys I won't keep the editor config tricks). 
In particular I'll try to identify where problems currently are, since that's 
what we want to address to maybe reach a consensus. I organized in topics, 
trying to keep both the concerns raised and the corresponding objection or 
adjustment proposals.

Please note that I tried to avoid citing people since I might have modified 
their statements without noticing, so I'd better avoid associating people to 
something they didn't say. ;-)

I hope it'll help...

***

1) Comments on the proposal

1.1) It's been done by a cabal.
Some people thinks that a not enough developers had a say in this proposal. 
They basically think it's a cabal trying to force a rule that won't be 
conformed to.

It has been objected that the key stakeholders in kdelibs code had no strong 
objection with such a rule.


1.2) It's a threat to our freedom.
Some people thinks that this proposal doesn't take care about the author 
choice since he wouldn't be able to choose the style he wants anymore. It's 
judged as a needless rule. It could demotivate some people to contribute to 
the project, in particular if the rule is strictly enforced (for instance, if 
patches get rejected for style reasons).

It's been objected that the author won't maintain the code forever anyway, and 
that sometimes it's not easy to figure what the original style was... 
resulting in the current style mess in several kdelibs files. It's also been 
said that consistency improves maintainability.


1.3) We should restyle whole kdelibs in one go.
The original proposal states that the style will be applied to new files, but 
for existing files the restyling occurs only on modifications. That would 
lead to an interim period with files having inconsistent style, which is 
acceptable for some people. They proposed to make a mass restyling first and 
get a consistent kdelibs now.

It has been objected that it would make "svn blame" unusable which is a very 
used feature.
For the youngest kdelibs parts (phonon for instance), a mass restyling could 
be done since they only have a couple of committers anyway.


1.4) Fine.
Of course, some people are just fine with the proposal. The consider such a 
thing as an improvement for kdelibs readability and unify here is a good 
thing because it's our most important shared piece of code.
(It would have been unfair to concentrate on disagreement only ;-) )


***


Since, some comments about the style itself are present in the thread, I'll 
keep them. I just hope I'm not opening the pandora box. Discussing the style 
itself is likely to lead to bikeshedding since it's really a matter of taste 
(no matter what people propose, red[R] is faster anyway...).

Anyway, please note that most people (not all) that issued a comment on the 
style also stated that they prefer it to be adopted as posted by Zack to 
avoid months of useless discussion.


2) On the style itself

2.1) 'Q' and 'q' prefix shouldn't be used.
I think everybody here agreed that this rule should be changed, and that 
public classes are prefixed with a "K" and public functions most often with 
a "k".


2.1) Brace placement
Some people would prefer having braces on their own line (instead of on the 
same line than the statement). But since the point was to avoid useless 
bikeshed on personal preferences, several of them are fine following the 
proposed style even against their own state.

It has been proposed that this rule could be removed or be made a two fold 
option.


***

That's the end of this summary attempt... it's already quite long. If I missed 
something feel free to add information by replying here and please accept my 
excuses.

Thanks for your attention.

Regards.

[R] http://red.bikeshed.org
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060724/90c0e086/attachment.sig>