kdelibs coding style

[Aaron J. Seigo]

On Saturday 22 July 2006 13:25, Maks Orlovich wrote:
> No, it's not. Yes, the proposed policy itself affects only kdelibs. But
> the /nature/ of the policy affects everyone. This sets a precedent that
> something that's merely a matter of preference and not technical merit can
> be legislated as a policy in the project. And in fact, even making kdelibs
> different in a way that's not technically neccessary (constract with e.g.
> BC), introduces a small but existing psychological barrier for contributors
> to jump into kdelibs from other modules. 

this contradicts every bit of experience i've ever had in software development 
and apparently others who have bothered to reply. for me, this includes doing 
exactly what is being suggested for kdelibs in kicker for the last 2 years. 
given that that is a kde project, let's do a comparison:

kicker had near zero contributors. adding a style guide didn't keep people 
out, in fact it brought greater consistency to the code base while an amazing 
number of new contributors showed up over those 2 years. it actually helped 
these new people figure out how to contribute. and my applying a HACKING file 
to kicker didn't make that spread to the rest of KDE apps; not even in the 
same module. nor did i try to make that happen.

when at the GIT workshop this week the instructor took out some time to 
discuss writing patches that have a hope in hell of making it into the linux 
kernel. one of the first things he mentioned was your patch must follow the 
coding style of the project otherwise you can assume it'll never get applied.

this coding style guide thing is extremely common both in industry and 
volunteer projects and does have benefits.

> (And don't bring up kdepim, please. 
> kdepim also has a long-lasting reputation for being hostile to new 
> contributors).

ouch. yellow card.

i've followed this particular project (kdepim) since i started following kde 
sometime in 2000 and i will state unequivocally that kdepim was horrific to 
get involved with during the 2.x and early 3.x work. i stopped contributing 
to that body of code specifically due to that. 

but then after yet anoter blow out the core group got together and worked out 
how to have a set of maintainers that everyone could work with .. and one of 
the things they did was to bring in a common hacking style. since then kdepim 
has been -much- better with new contributors and i've seen more new people 
since than before.

in fact, i'd say they aren't hostile to new contributors at all anymore. it 
was a reputation kdepim earned once many years ago but has since, IME and 
IMHO, grown beyond. part of that growth was getting their codebase in order.

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060722/94c1cc3e/attachment.sig>