OpenFrag Coding Guidelines

From OpenFrag

Jump to: navigation, search

In order to keep our code clean and consistent, we have set the following coding and style guidelines.

Contents

Code

Tabs and spaces

Our tab-width is 4 spaces. Tabs are never converted to spaces.

New lines and indentation

Before and after every opening parenthesis we use a new line, inside the parenthesis code and comments are indented by 1 tab. Comments after a closing parenthesis (on the same line) describe what the block was for.

for (int i = 0; i < 10; ++i)
{
	// indented by 1 tab
	int a = i;

	for (int j = 0; j < i; ++j)
	{
	 	// indented by 2 tabs
	 	int b = i - j;
	}
	// also indented by 1 tab
	
	for (int k = 0; k < i; ++k)
	{
	 	int c = k - i;
	}
} // for (i<10)    -- Note that we don't use this very often.

namespace openfrag
{
	class Core
	{
	}; // class Core	-- Note that we always use this on classes.
} // namespace openfrag		-- Note that we always use this on namespaces.

Virtual functions

For clarity, virtual functions should always carry the virtual keyword. This includes classes that derive from another class.

Class A
{
	virtual void doSomething();
}

Class B: public A
{
	// virtual is not required by C++, but is used for clarity.
	virtual void doSomething(); 
}

Commits

A few rules have to be set here:

  • Always update
  • Check if it compiles and is not broken before you commit
  • Check warnings and fix if possible
  • Check at least debug and release configs
  • Don't commit if there is noone around to verify your commit works
Personal tools
OpenFrag