Programming Style Guide

This is a very general overview and subject to change. If you have questions, contact .

Object Oriented

This is C++ not C so you will probably be writing or modifying classes. If you know a Class would never have any methods or be subject to inheritance a struct is fine. Typedefs are frowned upon unless it aids in portability.

Blocks

Use trailing braces when defining blocks.

Bad:

class Foo{
};

Good:

class Foo
{

};

Even for if/else/while/for blocks

Bad:

if (x > 0){
}

Good:

if (x > 0)
{

}

Don't use blocks if you don't need them

Bad:

if (x < 0)
{
    //Single Line if
}

Good:

if (x < 0)
    //Single Line if

An exception to this is is if you have an if/else where only one could be single line. Use blocks for both in that case.

Bad:

if (x > 0)
    //Single Line If
else 
{
   //Multi Line Else
}

Good:

if (x > 0)
{
    //Single Line If
}
else
{
    //Multi Line Else
}

Naming

Capitalize Class Names

class MyClass;

Capitalize Methods and Functions

void MyFunction();

Camel Case Members

class MyClass
{
    int myMember;
};

Camel Case Parameters

void MyMethod(int myParam);

Macros and Enums use CAPITAL_UNDERSORE

#define MY_PI 3.14159

enum MyEnum
{
    FIRST_VALUE,
    SECOND_VALUE
};

Commenting

Don't comment code that is self explanatory

Bad:

//This adds x to y
int Add(int x, int y)
{
    return x + y;
}

• If you are writing documentation that is a different story

Do comment code that is nuanced or complicated

Good:

//If you register a permission with a name that already exists, you will overwrite the existing permission
void RegisterPermission(const char* name, int id)
{
    //Code
}

All headers must be documented with Doxygen comments

We really don't want to have to go through the daunting task back tracking through old code to document it. If you're unfamiliar with Doxygen

Don't put spaces after single line comments

Bad:

// Comment

Good:

//Comment

Multi-line comments should not be on the same lines as the comment definition

Bad:

/* Multi
   Line
   Comment
*/

• This doesn't apply to documentation stubs

Good:

/*
    Multi
    Line
    Comment
*/

Multi-line comments should be tabbed once

Bad:

/*
Multi
Line
Comment
*/

Multi-line comments should not have a bunch of asterisks

Bad:

/*Multi
 *Line
 *Comment
 */

• This doesn't apply to copyright notices or documentation stubs

File Organization

File Naming and Folder Structure

• Use .h for headers and .cpp for source files
• Header and Source names should match or at least contain their class name
• Use multiple Source files where appropriate (MyClass.hpp, MyClass.cpp, MyClassWindows.cpp, MyClassLinux.cpp)
• Source files go in src/ and Headers go in include/

Example Header File

#pragma once

/*
    Copyright notice if applicable
*/

//Pre-Include Defines

//System level includes

//Project level includes

/*
    Any important info about MyClass
    OR 
    Info for documentation engine (cldoc / doxygen / etc)
*/
class MyClass
{
    friend class MyFriend;

public:
    //Static Methods
    
    //Static Variables

    MyClass();

    //Public Methods

    //Public Variables

    virtual ~MyClass();

protected:
    //Static Methods
    
    //Static Variables

    //Protected Methods

    //Protected Variables

private:
    //Static Methods
    
    //Static Variables

    //Private Methods

    //Private Variables
};

Notes:

• Do not use an #ifdef header guard

Example Source File

//Includes

//ALL Static Methods

//ALL Static Variables

MyClass::MyClass()
{

}

//Public Methods

MyClass::~MyClass()
{

}

/*
    Make a comment that you're now writing protected methods
*/

//Protected Methods

/*
    Make a comment that you're now writing private methods
*/

//Private Methods