The KWin Coding Style Situation

[Aaron J. Seigo]

On Sunday, November 28, 2010, Christoph Feck wrote:
> On Sunday 28 November 2010 20:20:33 Martin Gräßlin wrote:
> > From various discussion on IRC and looking through review requests, it
> > seems that we have a general problem with our coding style.
> 
> For kdelibs, we have a policy that only _new_ code needs to follow the
> style guidelines. Existing code is not reformatted. I would prefer
> switching to kdelibs style in kwin, but only for new code (i.e. new files
> or new functions).

kwin and kdelibs differ in some ways that are significant to this:

* kwin has just undergone a maintainership change and has "a" maintainer; 
kdelibs is maintained in pieces by a relatively large number of people and 
there is long term continuity of that maintainership

* kdelibs is developed in pieces (e.g. this class or that group of classes) 
rather than as a holistic whole, which kwin is; this means that kdelibs 
hacking is less affected by global consistency than kwin is.


so yes, a reformat will create an "opaque membrane" in the history of the 
repository, but wether that is actually a problem or not comes down to the 
development practices around kwin. e.g. how important is it to git bisect N 
months in the past?

ballance this (and how often the history is really used in this manner in 
kwin) with the benefits of code clarity in terms of keeping bar for 
contribution low and quality high.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101128/a76655e9/attachment-0001.sig