Gobelijn API documentation
- generated for commit a0cbea7
|
We use the approach to code convention and formatting proposed in Herb Sutter's "C++ Coding Standards", Guideline 0.
Basically, this guideline suggests not to be overly picky in regard to which convention you follow, but to be consistent in applying the one you choose. And to always remember that a convention is used to make code more readable. It is not a goal in itself.
For indentation, line breaking, brace positioning (i.e. the formatting) we follow Kernighan&Ritchie with some exceptions. They taht for class, method and function definitions we put the brace on the next line. For indentation (to quote As Sutter): indent to show structure. So, if you feel that the style does not do a good job at a particular point in the code, overrule it to make the indentation express the structure better.
Below we refer to the CamelCase name construction. This means that in multipart names each new part is started with a upper case. If the name is all upper case or all lower case, and then you use underscores to separate the parts.
Try avoiding the use of macros (except for conditional compilation), but if you are going to use them, they must always be all upper case.
The commenting style has to be consistent with doxygen usage. We expect a header with a brief description at least for each file and at least a brief description for each class. As for the rest: do not write comments that duplicate what the code expresses; write comment that shed some light on the rationale.
Generally, we adhere to the Java convention that puts a class in a like-named file. That makes it easy to find things. For C++ that means a header (.h) and implementation (.cpp) file with the class name.