beautifying code

[Ralf Funken]

Hi all,

>Hi KDevelop-team,
>
>I suggest we all should use nearly the same coding style in KDevelop
>because it's quite ugly to see different styles in one file.
>I would prefer a few rules:
>
>- prefix "m_" for class attributes
>- prefix "p" for pointers
>- prefix "m_p" for class attributes which are pointers
>- upper case letters for each single word in a compound word: e.g.
>KDevViewHandler instead of Kdevviewhandler.
>- tab space = 3
>- tabs replaced by spaces
>- prefix "b" for boolean variables
>- no prefix "get" at the beginning of a get function.
>
>Please, tell me your opinions. I just want to find a consense. :-)
>
>Cheers,
>   F at lk

I'm not coding for KDevelop, however I have an opinion. Thank you for 
listening :-))
I think it's a good idea to have one coding style. Falk's suggestions are 
quite near to the style we use in JAVA. There are two additional conventions:
1. function/method names always start lowercase, the remaining words start 
uppercase like in writeLine()
2. variablenames are always completely lowercase (same as in C/C++)
The KDevViewHandler example is used for classnames.

I don't think it's a good idea to use tabs2spaces because it's very 
difficult to correct if someone uses a different tab spacing. The other way 
round it's no problem ( in case you need it for <code> or <pre>).

Falk : Why do you want to eliminate the "get" prefix. IMO if an accessor is 
a getter it should be called like that.

One common code styling makes code more readable, easier to maintain and 
may help to find errors more quickly.  So thumbs up from here.

Some additional words about documentation
While the user docus are great, the internal docu is really bad. I'm not 
talking about comments, this is done quite well, but about the absence of 
an API documentation. It's almost impossible to get an overview in an 
acceptable amount of time. Most of you have been with the project right 
from the start, so you know every single corner of it and may not even 
notice that. But other programmers have to actually read the code to learn 
which functions and interfaces are defined. To be honest, that was one 
reason for me not to touch a thing in it, I don't have the time and no 
ambitions to read 10000 lines of code. But maybe it's too late to change 
that now.


Ralf



Ralf Funken

The KDevelop Project
http://www.kdevelop.org

Email:
RFunken at KDevelop.de
RFunken at KDevelop.org

PGP KeyID 0x06A3652D
Key fingerprint = A3 42 AC 8C 9A 54 6E DF  3F 2C 9E AB 10 2F 9E 3D