FreeCNC

FreeCNC - Linux Software and Games reviews

Coding Style

admin @ 8:28 am

Coding Style

This page contains our coding style guidelines. While we make every attempt to follow these, sometimes we don’t.

General Presentation

  • Four space indenting, no tabs.
  • Header guards follows the _DIR_FILENAME_EXT convention – _VFS_VFILE_H for vfs/vfile.h
  • Indent #ifdef/#ifndef etc the same as regular code. That is, like normal if/else statements.
  • Try to refrain from defining more than one variable per line. Parameters are the exception.
  • When declaring references or pointers, put *,& next to the type, not the variable.
    int x = 42;
    int& y = x;
    int* z = &x;
  • Where applicable, start the file with a comment explaining the contents. For headers, place it right after the header guards.
    //
    // Implements various Westwood format decoders
    //
  • For big files, seperate sparingly with headers or simple splitters.
    //--------------------------------------------------------
    // UnitType
    //--------------------------------------------------------
     
    UnitType::UnitType()
    {
        ...
    }
     
    UnitType::~UnitType()
    {
        ...
    }
     
    //--------------------------------------------------------
     
    UnitType::move()
    {
       ...
    }
  • In cases where it makes sense, try to keep 80 chars per line.
  • C++ style comments should be used for 1 liners. Never use /**/ for single line comments.
  • Use PascalCasing for classes, functions enums, and namespaces.
    enum Foo { TEST };
    class FooBar;
    void FooBar(int x);
  • Use ALL_UPPER_CASE for defines, enums values and macros (and dont use macros).
    #define VERSION "0.3.0"
    enum {
        RED,
        GREEN,
        BLUE
    };
  • Use underscores for words in variables.
    int foo_bar;
  • Curly braces go on their own lines for namespaces, classes, functions, and on the same line for control-flow statements.
    class Foo
    {
        ....
    }
     
    if (foo) {
        ...
    } else {
        ...
    }
  • Always use curly braces for control-flow statements that span several statements.
    GOOD:
         if (true) cout << ..;
    GOOD:
        if (true) {
            cout <<...;
        }
    BAD:
        if (true)
            cout <<...;
  • Simple functions, e.g. return 42, may be kept on a single line.
    int Foo() { return 42; }
  • Templates go on their own line.
    template <typename T>
    void Foo(T x);

Classes and structs

  • Use struct only when the object is entirely public, e.g. a stateless functor, or pure data.
  • Protection level is indented at the same level as the class. Also keep an empty line between different protection levels.
  • Organise the class in the order of public, protected, private.
  • Initializer lists go on their own lines, with the : and one indent level.
  • Inheritance goes on the same line as the class name.
  • For small inline methods, keeping them in the class definition is okay. For big inline methods however, define them below the class itself, in the header.
class Test : Parent
{
public:
    int public_var;
 
    Test();
    Test(const Test& test);
    ~Test();
 
    Test& operator=(const Test& rhs) { return *this; }
 
    void do_stuff();
 
private:
    Obj a;
    Obj b;
};
 
Test::Test()
    : a(42), b(60)
{
    ....
}


Leave a comment

Name (required)

Mail (will not be published) (required)

Website