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