-
Notifications
You must be signed in to change notification settings - Fork 1
Code Conventions
This is an excerpt of the Google C++ Style Guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml - retrieved April 2014) used for this library's code.
Function names, variable names, and filenames should be descriptive; eschew abbreviation.
Type names (classes, structs, ..) start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass, MyExcitingEnum.
Variable names are all lowercase, with underscores between words. Try to avoid multiple words. Class member variables have a leading 'm_'. For instance: local_variable, m_member_variable.
Use all capital letters with underscores: DAYS_IN_A_WEEK.
Regular functions have mixed case and start with a small letter. Use a verb as first word. For setters, use'set' as prefix: setCount(); for getters, use the variable name: count().
Name Enumerators like constants: APPLE, DAYS_IN_A_WEEK.
Namespace names are all lower-case, words are seperated by underscores and based on project names. awesome_project.
For single-line comments, use '// ', for multi-line comments use '/* */' and indent the contents.
// I am a single line comment
/*
This is a useful comment.
And we use multiple lines.
*/
Add the author and license to the top of every file.
Every class definition should have an accompanying comment that describes what it is for and how it should be used.
Declaration comments start with one sentence, that describes, what the function does. If needed, add a paragraph, that describes how to use the function. Optionally you can can add a comment at the definition that describes, how the function works. Getters and Setters don't need to be commented.
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. Each class data member (also called an instance variable or member variable) should have a comment describing what it is used for.
In your implementation you should have comments in tricky, non-obvious, interesting, or important parts of your code. Use a new line for the comment if the line gets too long.
Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.
Don't use a new line for the opening bracket.
if (x == 1) {
return z;
}
Minimal use of vertical whitespace.
Use one tab to indent code.
Return type on the same line as function name, parameters on the same line if they fit, opening bracket on the same line as parameters.
On one line if it fits; otherwise, wrap arguments at the parenthesis.
bool retval = doSomething(argument1, argument2, argument3);
bool retval = doSomething(argument1,
argument2,
argument3,
argument4);
Sections in public, protected and private order, each indented one time.
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 foo(). You may also want a mutator function setFoo(). Exception: static const data members (typically called FOO) don't need to be private.
Use the specified order of declarations within a class: public: before private:, methods before data members (variables).
Use const whenever possible.
Use a define-Guard to prevent double-including of definitions.
#ifndef HEADER_NAME
#define HEADER_NAME
/* Code */
#endif //HEADER_NAME
All parameters passed by reference must be labeled const.
Use C++ casts like static_cast<>(). Do not use other cast formats like int y = (int)x; or int y = int(x);.
Try to avoid lambda expressions, or the related std::function or std::bind utilities.
Avoid using Makros. Only use them, if there is just no other way.