DRAFT document on coding conventions in kde libraries

[Frans Englich]

On Sunday 05 March 2006 13:27, Olivier Goffart wrote:
> Hello,
>
> There is AFAIK not yet a document that tell conventions used in the KDE
> library. That's why I wrote one.
>
> I'd like to place it in developper.kde.org
>
> There is certainly still lot of typo, sorry for that.
>
> What have i forget ?

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

* 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.

* 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.

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..

> Do you like the idea ?

Yes, I like it very much. I think it's a great idea that things slowly 
harmonizes towards consistency and unity.

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..


Cheers,

		Frans