Consensus on the kdelibs coding style

[Friedrich W. H. Kossebau]

Am Samstag, 5. Juli 2008, um 17:10 Uhr, schrieb Ralf Habacker:
> Lubos Lunak schrieb:
> > On Thursday 03 of July 2008, Aaron J. Seigo wrote:
> >> i suggest to not restart this conversation every time the topic veers
> >> towards coding style
> >
> >  You know, you are actually right about this. It is pointless to have
> > such discussions repeatedly, especially given that they every single
> > time, including the first one, ended with no conclusion and just ignoring
> > it, getting tired of it or dismissing it as has-been-already-discussed
> > (which is kind of funny, given that those previous discussions never had
> > a conclusion). It is also silly to have some people pushing this way and
> > some the other way the way it's been happening. And, given that a coding
> > style is eventually bound to spread more and more, I think it makes sense
> > to finally sort this out. It's awfully late but awfully late is still
> > better than too late.
>
> The real reason for these problems are a missing feature in the used
> version control system. The was a statement that "People fears to loose
> history when applying a different coding style" - where does this come
> from ?
> The reason is that the diff logic for text files in svn (and the former
> cvs) are working line orientated not code token based for which white
> spaces and newlines are ignored. The conclusion is that for svn the
> coding style is part of the code tokens, which is indicated by the fact
> that any coding style change generates differences compared to the
> original code.
>
> A solution would be to store the code in the revision system
> independently from any coding style (or at least use a predefined coding
> style). When checking out code or diffing code a predefined coding style
> should be applied. Additional there should be a switch for selecting a
> checkout coding style to make people with other coding style preferences
> happy.
>
> That a demand for such a feature is there is shown by the 'Ignoring
> white space changes' topic, which is not more than an incomplete
> workaround.

+10 000

All the energy found in this thread and on this topic should really be spend 
to fix the broken way of storing the algorithm description.

In an ideal world all the code would be stored in a data model which resembles 
pretty much what this is all about, basically the AST. How the storing is 
really done and what language and format is used internally could be just a 
matter of the storage engine and optimised for it.

Then locally anybody would use an editor which is also capable of 
understanding the semantics of the data (and not just a linebased text editor 
with some addons). The editor one could be configed to use any textual syntax 
for the display of the algorithms/AST. Like C++ syntax, specialised with e.g. 
personal spacings and linebreaks rules. Some might even go with graphical 
syntaxes. 
</ideal world>

But this seems to be still stuck in academics and brains, has not made it into 
the real world of the year 2008, at least in my personal parallel universe. 
Because, fully-automation-based self-hosting code development and storing 
only has been around for some, wait, 40 years or that? Oh, inertia...

(And then there is this ugly linebased preprocessor thing with C/C++, still 
might be solvable with a two-stage approach.)

Cheers
Friedrich

PS: My wishes for real life: no tabs, per file consistency, self-documenting 
variable/structures/method names, compilable with standard compilers. Thanks.

-- 
Okteta - KDE Hex Editor, coming to you with KDE 4.1