kdelibs coding style

[Frans Englich]

On Sunday 23 July 2006 04: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.

I think people should see coding style as less about personal taste, and more 
about ensuring software quality. A consistent coding style improves 
maintainability and the source code quality in general. It's just as much 
about forcing into people's throats, as deciding on "you should comment your 
code".

It's not about us, it's about KDE. I don't see the KDE repository as an 
opportunity to express my personal tastes or write whatever code I feel like. 
I see it as working on KDE.

> 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.
>
> But here is a few points I want to make:
>
> 1. This tramples on code that perhaps only 1 person maintains.

If you take the short perspective. If you take the long perspective, you see 
that kdelibs is a mess. And this proposal solves that.

> 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? :)

Sure, I would love all C++ code in the world to have one style(or the whole of 
the KDE repository). However, it's not feasible to achieve, so I'm not going 
to suggest it.

Note how newer languages such as Python and Ruby largely removes the issue of 
coding style in the way the syntax is. That's pretty -- a language which not 
only focus on technical aspects, but also reduces friction in development 
teams.

> Consistent style _inside_ a file is important but consistent style _across_
> files even if you have nothing to do with them is contentious.
>
> 2. If people aren't respecting an existing file's style when editing the
> file, what's the likelihood that they are going to follow a new, global
> one?  With the current status quo, if you find a file with inconsistent
> style, feel free to change it.  Same with the new scheme so I doubt it will
> work - I predict no one will bother changing existing files.

I think it will work, although it would be dramatically helpt by a global 
re-indent. There's a difference between having countless of coding styles 
randomly spread and poorly documented(if at all), and a global, official, 
well-documented coding style.

>
> 3. Transparency
>
> > 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"

I think "the terms" are clear here. It's an all or nothing deal -- anyone is 
welcome to fully accept or fully reject(for whatever reason) the proposal.

It is like that for a reason. Since people think consensus cannot be reached, 
they don't attempt to. So, everyone think it's a pity it cannot be discussed. 
Anyone who has a suggestion for how to discuss it, are welcome to air it.

However, I'm positive towards discussing the details(for example, I think the 
braces part goes against what most people think), but there's no point in 
doing so if a consensus cannot be reached.

One could attempt a discussion, and if it fails, simply fallback to the 
Qt-paper.


Cheers,

		Frans