- 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 :)
- Please use the UNIX newline - LF. A good way to accomplish this is to enable the eol extension, we have .hgeol in the repository that will set it up.
- 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.
- 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.
- Don't use global variables. Exception: Sample code for platforms where we don't have a main function, e.g. Android.
- 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.
- When using camel case on a member function or variable with words in it that are typically fully capitalised (e.g. "OpenGL ES"), camel case them anyways, do not ever use underscores here! For example call the method isUsingOpenglEs instead of isUsingOpenGLES. The latter would be read more like "Open GLES", and the reader might end up wondering what "GLES" is.
- In CEGUI version 0.8.X local variables and function parameters should all be lower case with an underscore between words, such as in word_count and new_size.
- Starting with CEGUI version 1.X and in CEGUI default branch the local variables and function parameters should all be written in camel case, such as in wordCount and newSize.
- Boolean getter functions should always start with "is". Please think of meaningful names in that context, e.g. for plural, instead of "areCatsFuzzy" do NOT use "isCatsFuzzy" but use "isEachCatFuzzy" or "isEveryCatFuzzy", instead of "areVaosSupported" you could use "isVaoSupported", etc. Whatever you choose, make it both readable and grammatically correct. Sometimes opening a thesaurus may help you find the right words.
Code Formatting Style and Other Tips
- Code in general should be no more than 80 characters long per line. Long lines are more difficult to read and may lead to general bad programming practice. However there are cases when lines longer than 80 characters are appropriate, and in such cases it's allowed. However, no code line, ever, should be longer than 120 characters. Comments in code files should be split to lines at 80-character boundary. Here's an example where it's appropriate to exceed 80 characters in code lines. This is how it looks when split to 2 lines so as not to break the 80-character limit:
unsigned int glyph_bitmap_height =
static_cast<unsigned int>(glyph_bitmap->rows);
unsigned int glyph_bitmap_height = static_cast<unsigned int>(glyph_bitmap->rows);
- Tab spacing size should be 4. But...
- Do not use actual tabs, have your editor insert spaces instead. This is very important.
- In CEGUI default branch and CEGUI version 1.X or higher: When you override a function in a subclass, you must used the virtual and override keyword in the declaration, e.g.:
class BaseClass
{
virtual int overriddenFunction() = 0;
}
class SubClass
{
virtual int overriddenFunction() override;
}
- 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.
- In CEGUI default branch and CEGUI version 1.X or higher: For pointer comparisons and for setting pointers use only
nullptr. Do not use 0 and especially not NULL.
- In CEGUI 0.X: Only use
0 (not NULL) for pointer comparisons.
- 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 (primarily static_cast). C style casts should not be used. Or better yet, use a type consistently if possible so you do not need to cast in the first place!
- In CEGUI default branch and CEGUI version 1.X or higher: Only use
enum class for enums.
- In CEGUI 0.X: Only use regular
enum.
- In CEGUI default branch and CEGUI version 1.X or higher: You are encouraged to use C++11 features. However, be careful since some features are not available or not functional on all compilers that CEGUI supports. Known unsupported features are: string literals, thread_local and std::codecvt.
- In CEGUI default branch and CEGUI version 1.X or higher: We currently do not target C++14, so try not to use C++14 features unless they are available in all compilers that CEGUI supports (mind the minimum version we support).
- In CEGUI 0.X: Do not use any C++11 or C++14 features.
astyle - Artistic Style
The following parameters for astyle may be used to get a subset of all the code standards outlined in this document. It is by no means enough to just run this on dirty source code but it will get you closer.
$ astyle -s4A1wKfxpcUz2 $FILE
1.8.10