kdelibs coding style

Thiago Macieira thiago at kde.org
Sun Jul 23 01:05:04 BST 2006


Maks Orlovich wrote:
>Yes, I believe it can be a deterring factor. Let me explain: I would say
> that the general laissez-faire nature of KDE as a project, including
> the lack of indentation style played a heavy role in me becoming a KDE
> contributor. Why? First, there is a lot of intimidation factor in
> joining an open-source project, in hacking around. You naturally have
> to ask yourself whether you're good enough, whether you can imagine
> touching the same code as people like David and Waldo. And if the
> project implicitly says: here, you have an account, feel free to hack
> on whatever, just respect existing contributors' work, they're
> expressing TRUST in the new contributor. And yes, not having an
> indentation style is also expressing trust --- it's the project saying
> to the contributor "we're sure you can make your code nice and
> readable". Contrast this with projects that make you jump through tons
> of hoops, make one "prove one's worth". This is sort of why I make a
> big distinction between rules and suggestions; as the later retain
> trust in contributors to make the right decision.

Thank you for the explanation. Now I can understand your point of view.

I just want to ask you: how is the indentation style any more a deterring 
factor than all of the other policies we have now? A couple of examples:

1) the naming style:
	KClassName::camelCaseFunctionName
	KClassName::UpperCasedConstant

2) the namespacing style:
	classes in kdecore and kdeui aren't namespaced
	all other libraries are namespaced

3) the coding style:
	d-pointers
	Private or KClassPrivate (we haven't decided that yet)
	virtual hooks
	no private member variables

4) the binary compatibility guidelines
	no removing existing functions
	no reordering virtual functions
	no adding new virtual functions in non-leaf classes

Quite frankly, I'd think that #1 would be the most deterring factor for 
any new contributor. #2 would follow closely.

Any new contributor has to learn how to do that. Any new contributor 
should understand that the comments and criticism that more experienced 
developers give are not meant to "shoot down" the work, but to teach.

I wish someone had explained the uppercased constant rule for me when I 
created KExtendedSocket in KDE 2.2. I wish someone had explained why some 
of my tool classes didn't have to inherit from QObject.

If I were to rank the indentation guideline, I'd put it below all those 4 
above in a list of things that new contributors would have trouble 
adapting with.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060723/34c779a8/attachment.sig>


More information about the kde-core-devel mailing list