Code style guidelines

This is the coding style used for C/C++ code. Also see the Lua code style guidelines.

The coding style is based on the Linux kernel code style. Much of the existing code doesn't follow the current code style guidelines, do not try to replicate that. Use your best judgment for C++-specific syntax.

Spelling
Use American English, but avoid idioms that may be difficult to understand by non-native speakers.

Function declarations
In case your function parameters don't fit within the defined line length, use the following style. Indention for continuation lines is exactly one tab.

Sometimes with complex function declarations, it might be messy to define as many parameters as possible on the same line. This is acceptable too (and currently used in some places):

No more than 7 parameters allowed (except for constructors).

Spaces

 * Do not use spaces to indent.
 * Try to stay under 6 levels of indentation.
 * Add spaces between operators so they line up when appropriate (don't go overboard). For example:

The above code looks really nice.
 * Separate different parts of functions with newlines for readability.
 * Separate functions by two newlines (not necessary, but encouraged).
 * Use a space after,  ,  ,  ,  ,  ,  ,  ,  , etc.
 * When breaking conditionals, indent following lines of the conditional with two tabs and the statement body with one tab. For example:


 * Align backslashes for multi-line macros with spaces:

statements
This rule has already been explicitly stated in the Linux kernel code style from which this code style inherits, but it will be repeated here:

Putting the body of an  statement on the same line as the condition is strictly prohibited.

Example:

Violating this rule will result in instant rejection.

Examples of good if statement wordings:

Nested for loop exception
Special exception to the standard bracing/indent rules for nested loops: If a nested loop iterates over a set of coordinates, it is permitted to omit the braces for all but the innermost loop and keep the outer loops at the same indentation level, like so:

Do not be too C++y

 * Don't pass non- references to functions.
 * Don't use initializer lists unless absolutely necessary (initializing an object inside a class, or initializing a reference).
 * Try to minimize the use of exceptions.
 * Avoid operator overloading like the plague.
 * Don't use iterators when unnecessary.
 * Avoid templates unless they are very convenient.
 * Usage of macros is not discouraged, just don't overdo it like X.org. It's better to use inline functions instead.

Classes

 * Class names are PascalCase, method names are camelCase.
 * Don't put actual code in header files, unless it's a 4-liner, an inline function, or part of a template.
 * Class definitions should go in header files.
 * Substantial methods (over 4 lines) should be defined outside of the class definition.
 * Functions not part of any class should use.

Comments

 * Doxygen comments are acceptable, but please put them in the header file.
 * Don't make uninformative comments like this:


 * Add comments to explain a non-trivial but important detail about the code, or explain behavior that is not obvious.
 * For comments with text, be sure to add a space between the text and the comment tokens:

Use STL, avoid Irrlicht containers, and no, Boost will not even be considered, so forget it

 * In general, adding new dependencies is considered serious business.
 * We are using C++11; Boost will never be an option.

Don't let things get too large

 * Try to keep lines under 80 characters. It's okay if it goes over by a few, but 90 character lines or larger are definitely unacceptable. (Note that this column count assumes 4-space indents.)
 * Functions should not have over 200 lines of code – if you are concerned with having to pass too many parameters to child functions, make whatever it is into a class.
 * Don't let files get too large (over 1500 lines of code). Currently, existing huge files (, , …) are in the slow process of being cleaned up.

Files

 * Files should be named using snake_case style.
 * Files should have includes for everything that they depend on. Don't depend on, eg,  including  !
 * Uniqueness when compiling headers is ensured by using . (Accepted by all coredevs)


 * All files should include the appropriate license header.

Miscellaneous

 * Do not use, use.
 * Set pointer values to, not 0 (  is part of C++11).
 * When using floats, add the  suffix, e.g.   and not.
 * Do not use characters in C++ files from outside the ASCII character set.
 * Use of Hungarian notation is very limited. Scope specifiers such as  for globals,   for statics, or   for members are allowed. The prefix   is discouraged for public members in newer code as it is a part of the class' interface, but sometimes needed for consistency when adding a member to older code.
 * Don't use camelCase for local variables. Use snake_case instead.
 * Don't use distracting and unnecessary amounts of object-oriented abstraction. See Terasology as an example of what not to do.
 * As an addendum to the last point, don't add unnecessary design patterns to your code, such as factories/providers/sources.
 * In  statements, add   to the last case and to the   case.
 * In  statements, put the code which is more likely to be executed first.
 * For consistency, use American English where spellings differ (e.g. use "color", not "colour").