Home
Contents |
Spring engine coding standards
Status
This document is not yet finished. Please add new points whenever they occur to you.
Compiler
Keep in mind that we use gcc (g++) as the main compiler, likewise for linux and windows builds. So be sure your code compiles and works with gcc.
Directory structure
| build/ | stuff for the build systems (no C++ code) |
| ExternalAI/ | code to handle Global and Group AIs (not the actual AIs) |
| Game/ | Classes that keep the game running |
| Game/UI/ | The user interface |
| lib/ | Libraries distributed with spring (lua, streflop ...) |
| Lua | The Lua interface for the engine (don't confuse with the actual lua library, which is in lib/) |
| Map/ | All code related to map reading, drawing, mapdamage ... |
| Rendering/ | OpenGL helper classes |
| Sim/ | Everything related to the simulation (Pathfinder, Unithandler, LOS, ...) |
| System/ | Filesystem, Network, Memory Management as well as platform dependend code |
Style
Indentation
Use tabs, not spaces. This allows anyone to choose their favorite indentation size.
This implies that you should not use tabs in any other place then indentation. E.g. in the following sample use SPACE to align the constants.
#define LOS_INLOS 1 #define LOS_INRADAR 2
Do not attempt to align method parameters in a function call when breaking it over multiple lines. Just indent them using one or two tabs. Trying to align parameters with the opening parenthese is unmaintainable: next time someone refactors the code and changes the function name he has to go through all places it's used this way and waste his time inserting/removing spaces. Of course this applies to similar cases too; in general aligning stuff in such a way that an identifier rename requires realignment of all code using that identifier is bad practice.
Curly braces
For toplevel type (struct/class/union/enum) and function definitions, braces go on the next line:
class CMyClass
{
};
void MyFunction()
{
};
Non-toplevel types may use the same style as control flow braces.
For control flow, braces go on the same line:
if (condition) {
} else {
}
for (int i = 0; i < 10; ++i) {
do {
while (condition2) {
}
} while (condition1);
}
For if-else statements (and similar), the following is also fine:
if (condition) {
}
else {
}
Naming
In Spring engine code, concrete classes are prefixed with C, interfaces with I. Both use CamelCase. Functions and methods use CamelCase too. Parameters, fields, variables use pascalCase.
// interface
class IGlobalAI
{
};
// concrete class implementing interface
class CGlobalAI : public IGlobalAI
{
int myField;
void MyMethod();
};
There's two exception to this however:
- helper subclasses do not have any prefix, and
- value types neither (it's "float3", not "Cfloat3").
Filenames are usually identical to the name of the main class that's in it, with the prefix stripped off. For example, GlobalAI.cpp for class CGlobalAI.
General
Try to keep code as readable as possible. This means, do not write very long functions, but split the problem in multiple functions. Use identifier names with an actual meaning as opposed to a,b,c, etc. The point is to allow other devs to "read" the code, as opposed to "figure it out".
Keep classes dedicated to a single function, don't create big monolithic classes which no one understands.
External dependencies
Do not introduce new external dependencies without good motivation, the past has proven there are quite some libraries which just suck, don't build on some platform, are too buggy, make code unreadable, etc. If you really need to add a new dependency, be sure its cross platform, and favor dependencies that are already packages in big distributions like Debian or Ubuntu.
When working on Linux, remember to (get someone to) compile the dependency on Windows, both for MinGW and MSVC.
Sources
(This is good material to at least skim through; the first one is a must have for every serious programmer.)
- Code complete 2
- Philips Medical Systems - Coding Standard: C#, see: http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf