Coding convention

From Unvanquished
Jump to: navigation, search

The style for Daemon's source code should be the same as any other Quake-derived engine, and fairly self explanatory.

Name conventions

Filenames

Filenames only contains lowercase characters. If they contain more than one word, they are separated by underscores ("_").

typedef, struct & enum names

As for filenames, they only contains lowercase characters. Also, as for filenames, words are separated by underscores ("_").

  • struct names ends with "_s"
  • type names (typedef) ends with "_t"

function names

Their first character is lowercase, then, each new word starts with a uppercase letter.

variable names

Variable names follows function's rules.

local

cvar

They starts with the prefix "g_".

Function definitions

Function definitions are to be preceded by a C-style comment containing the function name, as follows:

/*
================
GL_TextureMode
================
*/

Note that the number of equals signs is constant regardless of function name length.

Parenthesis used in function calls and control structures are to be put off by their arguments by a single space, as are square brackets used for array subscripts. Code control structures get a space following the keyword, as well.

Spacing

Indentation

Indentation uses tabulation character.

Other spacing

Brackets

Brackets are separated from their content with a space, like that:

foo[ bar ] = foobar;
if ( foo )


Comparisons

Comparators are preceded and followed by spaces:

if ( foo == bar )

Variables names alignment

Variables names should be aligned:

foo    varName;
foobar varName2;

Blocks and instructions

There are no one-line block, nor multi-instructions line. If you need an if followed by only one line use something like that:

if ( foo )
{
  bar;
}

Assertions, self-documentation and dependency reduction

  • When a function takes a pointer as parameter, if this pointer should never be NULL, use an assertion to test it. It helps at debugging, but also to document the code.
  • When a function takes a pointer to a struct for read-only access, please mark it as a const pointer.
  • If a function only needs a subpart of a struct, pass only that subpart ( by example, if you only use gentity_t->playerState_t, only give it a playerState_t*)