DRAFT document on coding conventions in kde libraries

[Olivier Goffart]

Le Dimanche 5 Mars 2006 19:25, Frans Englich a écrit :

> Here are /ideas/. I don't know whether people find them good, but here they
> are for discussion:

Theses ideas are good, but my documents is more about libraries and API.
Theses point cover all code, even applications one.
A better place would be 
http://developer.kde.org/documentation/other/mistakes.html
or something like that.  (this document should maybe be in evidence also)

> * Mention that people should avoid C style casts. Especially in headers but
> also in implementation. From my knowledge: C++ style casts are stricter and
> therefore gives the compiler better options for statically detecting
> errors, and in some cases invalid casts are generated by C-style casts.

Yes,  use static_cast when the types are known at compile time.
If we are managing QObject childs, we should use qobject_cast which is faster 
than dynamic_cast 
(http://lists.kde.org/?l=kde-optimize&m=113179073130021&w=2)


> * Use the std namespace instead of the default. That is, include <iostream>
> instead of <iostream.h> since the latter is deprecated. (Good advice? No?)
> See: http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.4
>
> * Use constructor initialization. That is Foo::Foo() :
> m_member(QDate::currentDate()), or whatever. See:
> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6
>
> * Throw in a Note that people should document their code, and link to
> Adriaan's Doxygen howto.

Yes, I've already made this note at the end of the document

> I would maintain the document in Docbook in order to keep layout/structure
> consistent, and help with toc. One day we should keep the whole of
> developer.kde.org in Docbook for consistency, printability,
> maintainability, etc..

If ever i would known docbook.  But i can learn it anyway.

(What i mean is that i didn't made it docbook because i don't know this 
format, but if it's required, fine, i'll learn it)

> I would also like to see a uniform indentation policy, but that's probably
> the flamewar topic no. 1. A lot of code seems to use 4 whitespaces as
> indentation, and it would be nice to see that used consistently(or any
> other indentation). It wouldn't be about taste but consistency, and it
> wouldn't require that all code was converted. Just that a recommendation
> was there so things could over time harmonize in one direction. But I don't
> really suggest it, I think it's impossible to reach an agreement on this..

I'm not against it.
But /me looks at kate/kdevelop developer: if it would be possible to have the 
indentations thing depends of the project, and not of the application.
Because now, we should change our indentations preferences again and again 
each time we open another project.

-------------- 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/20060305/42dc31ef/attachment.sig>