kdelibs coding style

[mETz]

On Sunday July 23 2006 06:01, Clarence Dang wrote:
> On Thursday 01 January 1970 10:00, Zack Rusin wrote:
> > proposal for a common coding style  in kdelibs.
>
> I don't work on kdelibs but I do dislike the idea of forcing a common
> coding style up people's throats.  Nevertheless, I'm not going to object
> since many people seem happy about it.  Having said that, it's quite close
> to my style anyway except for the braces.

Just to mention it, the style does not follow my own style at all but that's 
not important because spaces vs. tabs does not have a big impact on 
readability, which is about the only point why I'd like to see a common style 
too.

> But here is a few points I want to make:
>
> 1. This tramples on code that perhaps only 1 person maintains.  What
> benefit is there in that other than pissing them off?  If consistent style
> across files is so important, why stop at kdelibs?  Why not force the whole
> of KDE to follow this new style?  Hell, why not force the Linux kernel to
> follow our 4-spaces tabs style as well? :)

I think you're exagerating a bit ;)
It makes perfect sense to unify kdelibs a bit because it is _THE_ shared part 
of KDE. Most people probably never looked at kview, juk or kmail but many 
many people did look at kdecore classes or even contributed a small patch. 
It's simple, the more people work with something, the more important rules 
become (although I have a great dislike for rules I can understand why 
they're needed).

> Consistent style _inside_ a file is important but consistent style _across_
> files even if you have nothing to do with them is contentious.

Usually application maintainers try to keep a certain style across their apps 
too, just see kdelibs as a huge application :)

> > please no adjustments. otherwise we'll discuss this till the cows come
> > home as people try and adjust this or that citing past changes as
> > precedent. =)
>
> This is like saying:
>
> "I am offering a totally open and transparent discussion.  However I refuse
> to negotiate any part of my proposal"

Yes, that's about the worst part of this discussion. I also have quite some 
problems with reading code that does not have curly braces on a line of their 
own.

Btw, I did not hear any argument _against_ having curly braces on a line of 
their own yet except for "but we don't want to change this style, either all 
or nothing"... ;)

Bye
Stefan aka mETz
-------------- 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/43fe94f9/attachment.sig>