Coding style guide - lodle/Desurium GitHub Wiki

In general, every .cpp file should have an associated .h file. There are some common exceptions, such as unittests and small .cc files containing just a main() function.

• All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be DESURA__H.

• Don't use an #include when a forward declaration would suffice. Inline Functions

• Define functions inline only when they are small, say, 10 lines or less. The -inl.h Files

• When defining a function, parameter order is: inputs, then outputs. Names and Order of Includes

• Place a function's variables in the narrowest scope possible, and initialize variables in the declaration. Static and Global Variables

• In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit init() method.

• Composition is often more appropriate than inheritance. When using inheritance, make it public.

• Use a struct only for passive objects that carry data; everything else is a class. Inheritance

• Only very rarely is multiple implementation inheritance actually useful. We allow multiple inheritance only when at most one of the base classes has an implementation; all other base classes must be pure interface classes tagged with the Interface suffix. Interfaces

• Classes that satisfy certain conditions are allowed, but not required, to end with an Interface suffix.

• Do not overload operators except in rare, special circumstances.

• Make data members private, and provide access to them through accessor functions as needed. Typically a variable would be called m_Foo and the accessor function getFoo(). You may also want a mutator function setFoo(). Exception: static const data members (typically called s_Foo) need not be private. Declaration Order

• Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc.

• Prefer small and focused functions.

• Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.

• Use the integer types defined in Common.h ([u]int[size], i.e. uint8, int64)

• Code should be 64-bit and 32-bit friendly. Bear in mind problems of printing, comparisons, and structure alignment.

• Be very cautious with macros. Prefer inline functions, enums, and const variables to macros. 0 and NULL

• Use 0 for integers, 0.0 for reals, NULL for pointers, and '\0' for chars.

• Use only approved libraries from the Boost library collection. Avoid including boost headers into module code and instead wrap them in a util library

• Currently using lambda's and auto.

• Function names, variable names, and filenames should be descriptive; eschew abbreviation. Types and variables should be nouns, while functions should be "command" verbs.

• Filenames should start with capital and follow type naming scheme

• Type names start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass, MyExcitingEnum.

• Variable names start with scope followed by an underscore, then type and then name. Scope can be m for class member g for global and s for static or none for local. Defined types are:

1. sz for strings

2. ui for unsigned int

3. i for signed int

4. f for float

5. p for pointer

6. v for vector

7. m for map

• Regular functions start with lower case and then have camel case except if you are overloading a wxWidget function which always start with a capital.

• Use // style and only use /* */ for the copy right

• Start each file with a copyright notice, followed by a description of the contents of the file.

• Every class definition should have an accompanying comment that describes what it is for and how it should be used.

• Declaration comments describe use of the function; comments at the definition of a function describe operation. Style is doxygen and all boundary classes must be documented.

• In general the actual name of the variable should be descriptive enough to give a good idea of what the variable is used for. In certain cases, more comments are required.

• In your implementation you should have comments in tricky, non-obvious, interesting, or important parts of your code.

• Pay attention to punctuation, spelling, and grammar; it is easier to read well-written comments than badly written ones.

• Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.

• Mark deprecated interface points with DEPRECATED comments.

• Non-ASCII characters should be rare, and must use UTF-8 formatting.

• Use only tabs

• Return type on the same line as function name, parameters on the same line if they fit.

• On one line if it fits; otherwise, wrap arguments at the parenthesis.

• Prefer no spaces inside parentheses. The else keyword belongs on a new line.

• Switch statements may use braces for blocks. Empty loop bodies should use {} or continue.

• No spaces around period or arrow. Pointer operators do not have trailing spaces.

• When you have a boolean expression that is longer than the standard line length, be consistent in how you break up the lines.

• Do not needlessly surround the return expression with parentheses.

• Your choice of = or ().

• The hash mark that starts a preprocessor directive should always be at the beginning of the line.

• Sections in public, protected and private order, each indented one tab.

• Constructor initializer lists can be all on one line or with subsequent lines indented a tab.

• The contents of namespaces are not indented.

• Use of horizontal whitespace depends on location. Never put trailing whitespace at the end of a line.

• Minimize use of vertical whitespace.

---

Mostly borrowed from http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml