Coding style

From Rigs of Rods Wiki

Jump to:navigation, search

{{nopdf:

Languages:

English • Help us translating

This article can be downloaded as PDF

1 Coding style for Rigs of Rods
2 Documentation
3 Other tips
- 3.1 Remove trailing whitespace
- 3.2 inden style

}} Why a set coding style is important
This project is an open source project. To get open source working as intended, many people should be able to comprehend the code. This implies that there is a well documented and uniform flow of code. That does not necessarily mean that a contributor should not write optimized yet cryptic code - one should always care about performance. However, other developers need to understand the code which means complicated parts of code must have good documentation.

Why we require that EVERYTHING is documented
What is simple to some might appear very complicated to others. Documentation helps these others. Anyone should be able to improve the code. But the main reason is, that when patch contributors want their patches added to the common codebase, the code needs to be reviewed by one or more developers. Documentation makes reviewing much easier.

Coding style for Rigs of Rods

Functions

Function names use CamelCase without underscores.
Opening curly bracket { for a function starts on the next line.
Use Foo() instead of Foo(void).

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

4cs, 6502acme, 6502kickass, 6502tasm, 68000devpac, abap, actionscript, actionscript3, ada, algol68, apache, applescript, apt_sources, asm, asp, autoconf, autohotkey, autoit, avisynth, awk, bascomavr, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c++, c_loadrunner, c_mac, caddcl, cadlisp, cfdg, cfm, chaiscript, cil, clojure, cmake, cobol, coffeescript, cpp, cpp-qt, csharp, css, cuesheet, d, dcs, delphi, diff, div, dos, dot, e, ecmascript, eiffel, email, epc, erlang, euphoria, f1, falcon, fo, fortran, freebasic, fsharp, gambas, gdb, genero, genie, gettext, glsl, gml, gnuplot, go, groovy, gwbasic, haskell, hicest, hq9plus, html4strict, html5, icon, idl, ini, inno, intercal, io, j, java, java5, javascript, jquery, kixtart, klonec, klonecpp, latex, lb, lisp, llvm, locobasic, logtalk, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, magiksf, make, mapbasic, matlab, mirc, mmix, modula2, modula3, mpasm, mxml, mysql, newlisp, nsis, oberon2, objc, objeck, ocaml, ocaml-brief, oobas, oracle11, oracle8, oxygene, oz, pascal, pcre, per, perl, perl6, pf, php, php-brief, pic16, pike, pixelbender, pli, plsql, postgresql, povray, powerbuilder, powershell, proftpd, progress, prolog, properties, providex, purebasic, pycon, python, q, qbasic, rails, rebol, reg, robots, ror, rpmspec, rsplus, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, systemverilog, tcl, teraterm, text, thinbasic, truck, tsql, typoscript, unicon, uscript, vala, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xbasic, xml, xorg_conf, xpp, yaml, z80, zxbasic

void ThisIsAFunction()
{
}

Variables

Variable names are all lowercase, and use "_" as separator.
Global variables must not be used
own members of classes should always be referenced using "this->"
Pointers and references should have their reference symbol next to the name (compatibility with current code).
Variables that are declared below one another should have their type, name or reference operator, and assignment operator aligned by spaces.
Declare variables upon first usage.
Always initialize variables with a default value. Do not use uninitialized variables.
Declare iterators in their loop.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

int     number         = 10;
Vehicle *u_first_wagon = v->next;
int     value          = v->value;

uint32 _global_variable = 3750;

protected:
    char protected_array[10];

for (int i = 0;;);

Give the variables expedient names, this increases the readability of the code

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

bool is_maglev_train = true;
if (!is_maglev_train) DoSomething();

Some people like to introduce copies of variables to increase readability, which can waste memory. However, in some cases, especially in code pieces which are often called, it makes sense to cache some calculated variables.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

/* Unoptimized code:
 * foo is not touched inside the loop!
 */
 for (uint8 i = 0; i < 100000; i++)
 {
  /* Do something */
  if (value_to_check == (foo * 4) % 5 + 6) DoSomething();
  /* Do something else */
 }

/* Better:
 * The used value of foo is calculated outside the loop.
 */
 const uint32 bar = (foo * 4) % 5 + 6;
 for (uint8 i = 0; i < 100000; i++)
 {
  /* Do something */
  if (value_to_check == bar) DoSomething();
  /* Do something else */
 }

Enumerations / static consts

Enumerations store integers that belong logically together (railtypes, string IDs, etc.).
Enumeration names also use CamelCase.
Enumerators are all caps with "_" between the words.
Enums are not used to store single numbers.
Enums have consecutive numbers OR
Enums have consecutive powers of two. Powers of two (bits) are written in hex or with the shift operator.
Enums may have special enumerators: "_BEGIN", "_END", and "INVALID_"). See example.
The invalid always has 0xFF, 0xFFFF, 0xFFFFFFFF as a value.
Other special values are consecutively less than the invalid.
Variables that hold enumerators should have the type of the enumeration.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

enum DiagDirection
{
	DIAGDIR_BEGIN = 0,
	DIAGDIR_NE  = 0,
	DIAGDIR_SE  = 1,
	DIAGDIR_SW  = 2,
	DIAGDIR_NW  = 3,
	DIAGDIR_END,
	INVALID_DIAGDIR = 0xFF,
	BROKEN_DIAGDIR = 0xFE,
};

enum
{
	DEPOT_SERVICE       = (1 << 0),
	DEPOT_MASS_SEND     = (1 << 1),
	DEPOT_DONT_CANCEL   = (1 << 2),
	DEPOT_LOCATE_HANGAR = (1 << 3),
};

DiagDirection enterdir = DIAGDIR_NE;

Numbers that store single or uncorrelated data are static consts. Those may use the naming conventions of enums.

Example:

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

static const int MAXIMUM_STATIONS = 42;

Comments on the enum values should start with "///<" to enable doxygen documentation

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

enum SomeEnumeration
{
	SE_BEGIN = 0,        ///< Begin of the enumeration, used for iterations
	SE_FOO = 0,          ///< Used for xy
	SE_BAR,              ///< Another value of the enumeration
	SE_SUB,              ///< Special case for z
	SE_END,              ///< End of the enumeration, used for iterations
};

Control flow

Put a space before the parentheses in "if", "switch", "for", and "while" statements.
In if/else, switch, and loop statements, following statements should be inside brackets on a different line.
Opening curly bracket { goes to the next line (not the same)
In if without an else statements, a single statement may follow on the same line.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

if (a == b)
{
  Foo();
} else {
  Bar();
}

if (a == b) Foo();

switch (a)
{
  case 0: DoSomethingShort(); break;

  case 1:
    DoMore();
    b = a;
    break;

  case 2:
  {
    int q = 345;

    DoIt();
    break;
  }
}

for (int i = 0; i < 10; i++)
{
  Foo();
  Bar();
}

Classes

Classes names also use CamelCase.
Classes should have "public", "protected", and "private" sections.
Within these section the order is: types, static const members, static members, members, constructors / destructors, static methods, methods.
Deviations from above order are allowed when the code dictates it (e.g. a static const is needed for a typedef)
Methods and members ought to be grouped logically.
All those sorting rules sometimes conflict which one another. Please use common sense what increases legibility of the code in such a case.
The method implementation should indicate if it is virtual or similar by using a comment.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

class ThisIsAClass
{
public:
    typedef Titem_   *ItemPtr;
private:
    static const int MAX_SIZE = 500;
    int              size;
    ItemPtr          *items;

public:
    explicit ThisIsAClass();
   ~ThisIsAClass();

    virtual void Method();
};

/*virtual*/ void Class::Method()
{
    this->size *= 2;
}

Templates

Templates are a very powerful C++ tool, but they can easily confuse beginners. Thus:

do not use templates if possible.
Templates are to be documented in a very clear and verbose manner. Never assume anything in the documentation.
the template keyword and the template layout get a separate line. typenames are either "T" or preceded by a "T", integers get a single capital letter or a descriptive name preceded by "T".

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

template <typename T, typename Tsomething, int N, byte Tnumber_of_something>
int Func();

If you are writing one or more template class in the dedicated header file, use file.hpp for its name instead of file.h. This will let others know that it is template library (includes also implementation), not just header with declarations.

Other important rules

Put a space before and after binary operators: a + b, a == b, a & b, a <<= b, etc.. Exceptions are ".", "->" and "[]" (no spaces) and "," (just space after it).
Put brackets where it improves readability: *(b++) instead of *b++.
Do not put external declarations in implementation (i.e. cpp) files.
Use const where possible.
Do not typedef enums and structs.
Don't treat non-flags as flags: use "if (char_pointer != NULL && *char_pointer != '\0')", not "if (char_pointer && *char_pointer)".
No trailing whitespace. The svn server will not allow tabs or space on the end of lines.
Only use tabs to indent from the start of the line.
Use /* */ for single line comments.
Use // at the end of a command line to indicate comments.

Documentation

We use Doxygen to automatically generate documentation from the source code. It scans the source files for recognizable comments.

The doxygen user manual can be found there: http://www.doxygen.nl/manual.html

Make your comments recognizable.

Files

Put a @file command in a JavaDoc style comment at the start of the file, followed by a description.

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

 /** @file
  * This is the brief description.
  * This is the detailed description here and on the following lines.
  */

Warning
If a file lacks a file comment block then NO entities in that file will be documented by Doxygen!

Functions

Comments for functions go in the .h file.
Comments for inlines go in the .h file.
Small inlines can have a short 3 or 4 line JavaDoc style comment.
Completely document larger functions.
Document obvious parameters and return values too!

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

/**
 * A brief explanation of what the function does and/or what purpose it serves.
 * Then follows a more detailed explanation of the function that can span multiple lines.
 *
 * @param foo Explanation of the foo parameter
 * @param bar Explanation of the bar parameter
 * @return The sum of foo and bar (@return can be omitted if the return type is void)
 *
 * @see SomeOtherFunc()
 * @see SOME_ENUM
 * 
 * @author Bjarni, Darkvater
 * @bug Some bug description
 * @bug Another bug description which continues in the next line
 *           and ends with the following blank line
 *
 * @todo Some to-do entry
 */
static int FooBar(int foo, int bar)
{
  return foo + bar;
}

Classes

Document structs similarly to functions:

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

/**
 * A short description of the struct.
 * More detailed description of the its usage.
 *
 * @see [link to anything of interest]
 */
struct foo
{
}

JavaDoc structural commands

This table shows the commands you should use. The full list is here.

Command	Action	Example
@attention	Starts a paragraph where a message that needs attention may be entered. The paragraph will be indented.	@attention Whales crossing!
@author	Starts a paragraph where one or more author names may be entered. The paragraph will be indented. Multiple adjacent @author commands will be joined into a single paragraph and separated by commas. Alternatively, one @author command may mention several authors.	@author Bjarni
@brief	Starts a paragraph that serves as a brief description. For classes and files the brief description will be used in lists and at the start of the documentation page. For class and file members, the brief description will be placed at the declaration of the member and prepended to the detailed description. A brief description may span several lines (although it is advised to keep it brief!).	@brief This is the brief description.
@bug	Starts a paragraph where one or more bugs may be reported. The paragraph will be indented. Multiple adjacent @bug commands will be joined into a single paragraph. Each bug description will start on a new line. Alternatively, one @bug command may mention several bugs.	@bug Memory leak in here?
@note	Starts a paragraph where a note can be entered. The paragraph will be indented.	@note Might be slow
@todo	Starts a paragraph where a TODO item is described. The description will also add an item to a separate TODO list. The two instances of the description will be cross-referenced. Each item in the TODO list will be preceded by a header that indicates the origin of the item.	@todo Better error checking
@warning	Starts a paragraph where one or more warning messages may be entered. The paragraph will be indented.	@warning Not thread safe!
	Function related commands
@return	Starts a return value description for a function.	@return a character pointer
@param	Starts a parameter description for a function parameter with name <parameter-name>. Followed by a description of the parameter. The existence of the parameter is checked and a warning is given if the documentation of this (or any other) parameter is missing or not present in the function declaration or definition. The @param command has an optional attribute specifying the direction of the attribute. Possible values are "in" and "out".	@param n The number of bytes to copy @param[out] dest The memory area to copy to. @param[in] src The memory area to copy from.
@see	Starts a paragraph where one or more cross-references to classes, functions, methods, variables, files or URL may be specified. Two names joined by either :: or # are understood as referring to a class and one of its members. One of several overloaded methods or constructors may be selected by including a parenthesized list of argument types after the method name. Here you can find detailed information about this feature.	@see OtherFunc()
@b	Displays the following word using a bold font. Equivalent to <b>word</b>. To put multiple words in bold use <b>multiple words</b>.	...@b this and @b that...
@c / @p	Displays the parameter <word> using a typewriter font. You can use this command to refer to member function parameters in the running text. To have multiple words in typewriter font use <tt>multiple words</tt>.	... the @p x and @p y coordinates are used to...
@arg / @li	This command has one argument that continues until the first blank line or until another @arg / @li is encountered. The command can be used to generate a simple, not nested list of arguments. Each argument should start with an @arg / @li command.	@arg @c AlignLeft left alignment. @arg @c AlignCenter center alignment. @arg @c AlignRight right alignment
@n	Forces a new line. Equivalent to and inspired by the printf function.	@n

More on Doxygen and JavaDoc

Doxygen knows two different kinds of comments:

Brief descriptions: one-liners that describe the function roughly (example)
Detailed descriptions: as the name suggests, these contain the detailed function/purpose of the entity they describe (example)

You can omit either one or put them into different places but there's only one brief and one detailed description allowed for the same entity.

Doxygen knows three modes for documenting an entity:

Before the entity
After the entity
In a different file

The latter is a little harder to maintain since the prototype of the entity it describes then is stored in several places (e.g. the .h file and the file with the descriptions). Also while it makes the code easier to read it also makes it easier to omit the important step of updating the description of an entity if it was changed - and we all know why that shouldn't happen ;)
Because of those reasons, we will only use the first two documentation schemes.

Doxygen supports both Qt and JavaDoc comment styles:

Qt style example: int i; //!< The counter for the main loop
JavaDoc style example: int i; /**< The counter for the main loop */

It also supports more comment styles but those two are the ones which are standardized. For OTTD we'll be using the JavaDoc style. One of the reasons is that it has a feature that the Qt style doesn't offer: JavaDoc style comment blocks will automatically start a brief description which ends at the first dot followed by a space or new line. Everything after that will also be part of the detailed description.

The general structure of a JavaDoc style comment is

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

 /**
  * This is the brief description. And this sentence contains some further explanations that will appear in the detailed description only.
  */

and the resulting descriptions of that block would be:

Brief description: This is the brief description.
Detailed description: This is the brief description. And this sentence contains some further explanations that will appear in the detailed description only.

The distinction between the brief and detailed descriptions is made by the dot followed by a space/newline, so if you want to use that inside the brief description you need to escape the space/newline:

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

 /**
  * This is a brief description (e.g.\ using only a few words). Details go here.
  */

If you're doing a one-line comment, use:

Invalid language.

You need to specify a language like this: <source lang="html4strict">...</source>

Supported languages for syntax highlighting:

 int i; ///< This is the description.

Also in the comment block you can include so-called structural commands which tell Doxygen what follows. In general, their area of effect begins after the command word and ends when a blank line or some other command is encountered. Also, multiple occurrences of the same structural command within a comment block or the referring entity will be joined in the documentation output usually.

Other tips

Remove trailing whitespace

To find out if/where you have trailing whitespace, you can use the following (unix/bash) command: grep -n -R --include "*.[ch]" '[ ]$' * | grep --invert-match ".diff" | grep --invert-match ".patch" Automatically removing whitespace is also possible with the following shell script (Note that it only checks .c, .cpp, .h, .hpp and .mm files):

#!/bin/sh
IFS='
'
for i in Makefile `find . -name \*.c -o -name \*.cpp -o -name \*.h -o -name \*.hpp -o -name \*.mm`
do
  (
    echo '%s/[ 	]\{1,\}$/'
    echo w
    echo q
  ) | ed $i 2> /dev/null > /dev/null
done

inden style

indent RoRFrameListener.cpp -o RoRFrameListener2.cpp -bl -bli0 -cdw --use-tabs -i8 -bap -bad -bbb -ss -npcs -ncs -nbc -psl -bls -blf -ip8 -ppi1 -l9999 -lc9999 -nfca -lp -npsl -sc

Retrieved from "http://www.rigsofrods.com/wiki/index.php?title=Coding_style&oldid=12327"

Categories:

Quick Jump

Navigation

Toolbox

Namespaces

Variants

Views

Actions

Search

Coding style

From Rigs of Rods Wiki

Contents

Coding style for Rigs of Rods

Functions

Variables

Enumerations / static consts

Control flow

Classes

Templates

Other important rules

Documentation

Files

Functions

Classes

JavaDoc structural commands

More on Doxygen and JavaDoc

Other tips

Remove trailing whitespace

inden style