Consensus on the kdelibs coding style

[David Jarvie]

On Sat 5 July 2008 21:53:10 Aaron J. Seigo wrote:
> On Saturday 05 July 2008, David Jarvie wrote:
> > On Sat 5 July 2008 20:25:19 Maksim Orlovich wrote:
> > > > this discussion was had quite thoroughly, including on this list.
> > > > this is the
> > > > one point there was broad consensus on, in fact. restarting
> > > > conversations evern N months is not useful, and we have mailing list
> > > > archives for this purpose.
> >
> > When this was discussed previously, I didn't think to question the
> > desirability of relatively detailed coding rules. I happen to have had
> > the new (to me) thought that this isn't actually necessary. That's why I
> > voiced this opinion. Or is that not allowed?
>
> it's not a matter of "allowed" or "not allowed". it's a request to keep
> things moving rather than stalling by re-iterating conversations. it's a
> bad habit we have in kde: keep repeating ourselves until we get what we
> want.

I don't dispute the need for *some* rules. I was talking about *what* rules 
there should be, just as Lubos was - I basically agree with him. Unless I'm 
mistaken, that is what this thread is about.

> you are free to code however you want in your projects. when you are
> working with others, however, there's a certain amount of "working with
> others" that ought to come into it. that "working with others" extends to
> coding style for people working on kdelibs, just as it does to people
> working on kdepim, plasma, etc.
>
> what you're really asking for is for those who are working on these code
> bases to not set guidelines for their projects. that's a freedom each team
> should have, imho.

I presume that we're discussing the kdelibs coding style here, not that for 
other projects.

> > justification for an official coding style is to ensure code is readable.
>
> readable, maintainable, etc. yes.

Yes, maintainability is another good justification.

> > That doesn't require detailed rules.
>
> they are guidelines, not rules, and they aren't exactly detailed. i have a
> binder here that's 2 inches thick on coding style from a government project
> that's detailed ;) so yes we can also discuss what is detailed and what
> isn't.
>
> the current guidelines are not onerous. they haven't caused problems in the
> code or the pace at which the code is being worked on.

I'm worried that the current guidelines which became "official" without any 
clear agreement on the lists will eventually become rules by means of a 
similar non-transparent process.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm