kdelibs coding style
Aaron J. Seigo
aseigo at kde.org
Sat Jul 22 23:21:57 BST 2006
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
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
Size: 191 bytes
Desc: not available
More information about the kde-core-devel