- Author
- Paul D Turner
This page details the coding standards and general style that should be employed when working on code for the CEGUI project. I am well aware that some of the existing code does not comply with these standards; though all new code should now be written to comply, and older code will be migrated over a period of time.
Files
Here we describe the requirements relating to files; their naming, layout and arrangement on disk.
Naming and Directory Layout
This section contains some general guidelines on naming and arranging files.
- The source code in general exists in two groups; the library code itself, and code for the sample browser and sample application modules:
- The library code, beneath the cegui directory, is contained within dual directory trees - one beneath the src directory to contain all the implementation .cpp files, and one beneath the include/CEGUI directory to contain all the header .h files. Within these directories, there is a seperate subdirectory for each group of modules or subcomponents within the system. For example there are subdirectories for RendererModules and XMLParserModules to hold the renderer module code and XML parser module code respectively; these directories then have further subdirectories for each individual module.
- The sample code, beneath the samples directory, has individual directories for each sample application. The implementation and header files for the sample should both appear together in this directory; there should be no separate src and include subdirectories for the samples.
- File names should not contain spaces, although the use of the underscore is acceptable where neccessary.
- File names should the initial letter of each word captialised.
- Files should generally be named after the class or module to which they relate. For example, the file MyClass.h would be the main header for the class named MyClass.
- Source files within CEGUI should use the following convention:
- C++ header files should have the .h file extension.
- C++ source files should have the .cpp file extension.
- Lua source files should have the .lua file extension.
- Extra Doxygen documentation files should have the .dox file extentsion.
General Structure and Layout
- All source files are required to have the basic file header that can bee seen in existing files. The information in the header is the filename, the date the file was created, the name and email address of the person who created the file, and the standard copyright/license notice as follows:
- All header files should have include guards implemented via preprocessor
#ifdef/#endif commands. We do not want any pragma rubbish used for this as it's worse than useless as far as being portable goes. The macro used to control the header should be based upon the filename.
- Please ensure that all files have a newline at the end of them. Depending upon the layout of included files and various other things, not having a newline has the potential to cause code not to compile correctly - especially in relation to headers. Plus it gives loads of annoying warnings on some compilers :)
- Wherever possible preprocessor macros should not be used. Always prefer the use of an actual language construct (such as typedef or enum) over a preprocessor
#define.
- Wherever possible header files should contain Doxygen documentation for all classes, data and functions. There will be very few, if any, exceptions to this rule.
- In source files, definitions of the various data groups and each member function should be separated by a line, thus:
- Implementation code belongs in the implementation .cpp files, not in the header files. There are very few cases, such as for template implementation, where c++ code should appear in header files.
- The general content of a header file should be in the following order:
- File header.
- Include guard.
- #include statements (grouped according to library where appropriate).
- Preprocessor macro defines (especially try to avoid these in headers).
- Class forward references.
- Global declarations.
- Class declarations.
- Code implementaions - for example, for templatised functions.
- The general content of a source file should be in the following order:
- File header.
- #include statements (grouped according to library where appropriate).
- Preprocessor macro defines (avoid where possible).
- Global definitions.
- Class static data definitions.
- Class member function definitions.
Code Style and Layout
The following details the general code style and layout that should be used.
Naming Conventions for Types, Variables, Members and Constants
- Preprocessor macro names should be all upper case with words separated by the underscore character. Wherever possible, do not use preprocessor macros. A general exception to this particular rule is the name of include guards which may have case matching that of the header filename.
- All types (namespaces, classes, structs, typedefs and enums) should have descriptive names and use PascalCase; where each word of the name is capitalised - such as in MyClass.
- Constants should be all upper case with words separated by an underscore, such as in THIS_IS_CONSTANT. Please note that this rule does also apply to class member constants and enumeration values.
- Global variables should use camel case; where each word in the name is capitalised except the first word. Globals should be prefixed with G_. So if we had a global we want to call 'nastyVariable' it should be named G_nastyVariable - yes, it looks horrible, and hopefully it's horrible enough that you find another way!
- Class member variables should be camel case; where each word in the name is capitalised except the first word, such as in thisVariable. Normal members should have the prefix d_ (for data, don't ask!), such as in d_thisVariable, while static members should have the prefix s_, such as in s_anotherVariable.
- Class member functions should be camel case; where each word in the name is capitalised except the first word, such as in theFunction. Member functions do not use prefixes.
- Local variables in functions should be all lower case with an underscore between words, such as in word_count.
- Parameter names are treated the same as other local variables, so should be named all lower case with an underscore between words, such as in char_count.
Code Formatting Style and Other Tips
- Generally speaking no line in any file - whether code or just plain text - should be more than 80 characters long. Long lines are really hard to read and lead to general bad programming practice.
- Tab spacing size should be 4. But...
- Do not use actual tabs, have your editor insert spaces instead. This is very important.
- Code within functions should be split into logical groups by the use of blank lines where appropriate. Generally any control structure (if, while, case, do and so on) should be both preceded and followed by a blank line.
- Regarding comments, we prefer well written, self documenting code that requires no comments. However, if it is deemed a comment is needed, write the comment first; always put it before the line or block it pertains to. This helps to ensure the comment indicates the intent of the code that you then write, rather than parrotting what is obvious from the code, which tends to happen when adding comments afterwards - we can already see what the code does, what we're interested in is it's purpose; the why as opposed to the what.
- Any and all braces opening a code block should be on their own line, and not attached to the control structure that came before. That is, like this:
if (something == 1)
{
...
}
if (something == 1) {
...
}
- Class declarations should not have the protection level specifiers indented. It should be like this:
class SomeClass
{
public:
SomeClass();
};
class SomeClass
{
public:
SomeClass();
};
- Namespace content should not be indented; it wastes too much line space. It should be like this:
namespace SomeNamespace
{
class SomeClass
{
public:
SomeClass();
namespace SomeNamespace
{
class SomeClass
{
public:
SomeClass();
- Switch case statements should not be indented, though the case code should. Any required braces should appear in line with the case to which they pertain, such as in:
switch (somevar)
{
case 1:
x = x + 1;
break;
case 2:
{
int y = 2;
x = x + y;
break;
}
}
switch (somevar)
{
case 1:
x = x + 1;
break;
case 2:
{
int y = 2;
x = x + y;
break;
}
}
- The general layout of a function definition (in the .cpp source file) should have the return type on the same line, such as this:
std::string SomeClass::getString(const char* c_str)
{
...
}
- Use of single line code blocks both with or without braces for loop and condition constructs is allowed. Though generally you should prefer the form without braces.
if (something == true)
doSomething();
if (something_else == true)
{
doSomethingElse();
}
- Having multiple statements on a single line is not allowed, even for control structures. Each statement should be on its own line. Code should be like this:
if (x == 0)
x = 1;
x = 2;
x += y;
if (x == 0) x = 1;
x = 2; x += y;
- There should be a space between a control statement and its control expression. Use this: Not this:
- When calling a function, there should be no space between the function name and the parenthesis containing the arguments. So, like this:
an_object->callFunction(x, y, x);
an_object->callFunction (x, y, x);
- There should generally not be spaces around parenthesis (unless otherwise excepted above). Code should look like this:
a = calculate((x + y) * z);
a = calculate( ( x + y ) * z );
- There should be spaces both sides of virtually all operators, except the comma which just has one following it. An example of correct usage is:
a = calculate((x + y) * z);
b = doSomething(a, x, y);
a = calculate((x+y)*z);
b=doSomething(a,x , y);
- When creating a pointer or reference variable the asterisk or ampersand should be attached to the type name not the variable name. These are correct:
SomeClass* class_ptr;
SomeClass& class_ref = an_object;
SomeClass *class_ptr;
AnotherClass * another_ptr;
SomeClass &class_ref = an_object;
- When dereferencing a pointer or taking the address of some object, the asterisk or ampersand should be attached to the variable name, like this:
SomeClass& class_ref = *class_ptr;
a_ptr = &an_object;
- String and/or character literals should not appear in production code; use constant definitions instead.
- Magic numbers should not appear in production code; use constant definitions instead. In general the only number that may appear in production code is
0.
- Use of
NULL is not allowed; use 0 instead. NULL is just a macro definition and does not exist in any other form in the C++ language, so it should not be used.
- When defining class constructors, use of member initialiser lists is to be strongly preferred over the use of assignments in the constructor body.
- Only use C++ style casts. C style casts should not be used. Or better yet, find a way not to use the cast at all!
- Do not use any language or STL constructs from C++11. We intend to support non-c++11 compilers for the forseeable future.
1.8.3.1