Consensus on the kdelibs coding style

Ralf Habacker ralf.habacker at freenet.de
Sat Jul 5 16:10:08 BST 2008


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.

Just my 2 cents.

Ralf





More information about the kde-core-devel mailing list