overcrowded / Solipsis Coding Rules

Coding Rules and Guidelines

C++ should conform to the ANSI C++ standard draft :
http://www.kuzbass.ru:8086/docs/isocpp/

Have also a look to the Ogre project recommendations :
http://temas.obelisk.net/ogre/CR/docs/howto.html

General Guidelines

1. Provide plenty of comments (in English, Doxygen compliant)
2. All code should be also written in English
3. Don't reinvent the wheel, use clever dependencies!
4. Use only open sourced projects as dependencies
5. Avoid platform dependant stuff as possible
6. Must compile at least on Debian ( GCC 4) and Windows 32bit platform (VC++2005) as Ogre do
7. Avoid DirectX? or OpenGL? dependant routine (use Ogre!)
8. Code for clarity rather than efficiency
9. Code defensively, check return codes and don't assume success
10. Use meaningful names (not i, ii, iii and j)
11. Indent nested blocks
12. Avoid implicit data-type conversions, use explicit conversions
13. Avoid complicated "if"' constructs
14. Avoid global variables as possible

Rules for C++ code

1. C/C++ include files have the extension .h
2. C++ source files have the extension .cpp
3. C source files have the extension .c
4. Use a separate .cpp and corresponding .h file for each C++ class. The filename should be identical to the class name
5. Do not create classes/files whose names differ only by case
6. Data members should have names beginning with a leading 'm'
7. Prefer standard C++ library and STL functions over C stdlib functions
8. Include directives should be of the form #include "<package>/file.h"
9. Use existing classes where possible
10. Encapsulate your global variables, constants, enumerated types and typedefs in a class
11. Avoid overloading functions and operators unless it brings clear improvements
12. Do not treat pointers as booleans, i.e. never implicitly compare pointers to nonzero
13. Routines that do not have a void return type should always return something (i.e. no "return;")
14. Preconditions and postconditions are checked with assert(<condition>)
15. Long, complex in-line member functions should be avoided. Don't inline anything that calls something else, or involves significant control structures
16. Use "bool", not "int", for true/false data items
17. 0 should be preferred over NULL
18. Use enums for small named constants within classes. Do not use #define for this because it can result in name collisions in other people code
19. Use "const" whenever possible
20. Never use #include when a simple forward declaration ("class foo;") will do

---