12.11
Google C++ Style Guide
1. Default Arguments
Can a virtual function have default arguments?
Default Arguments are allowed on non-virtual functions when the default is guaranteed to always have the same value. Follow the same restrictions as for function overloading, and prefer overloaded functions if the readability gained with default arguments doesn't outweigh the downsides.
2. Trailing Return Type Syntax
Use trailing return types only where using the ordinary syntax is impractical or much less readable.
3. Ownership and Smart Pointers
Prefer to have single, fixed owners for dynamically allocated objects. Prefer to transfer ownership with smart pointers.
4. cpplint
Use cpplint.py to detect style errors.
5. General Naming Rules
Names should be descriptive; avoid abbreviation
6. File Names
Filenames should be all lowercase and can include underscores (_) or dashes (-). Follow the convention that your project uses. If there's no consistent local pattern to follow, prefer "_".
7. Type Names
Type names start with a capital letter and have a capital letter for each new word, with no underscores: MyExcitingClass
8. Variable Names
The names of variables (including function parameters) and data members are all lowercase, with underscores between words. Data members of classes(but not structs) additionally have trailing underscores.
9. Constant Names
Variable declared constexpr or const, and whose value is fixed for the duration of the program, are named with a leading "k" followed by mixed case. Underscores can be used as separators in the rare cases where capitalization cannot be used for separation.
10. Function Names
Regular functions have mixed case; accessors and mutators may be named like variables. Ordinarily, functions should start with a capital letter and have a capital letter for each new word.
11. Namespace Names
Namespace names are all lower-case. Top-level namespace names are based on the project name. Avoid collisions between nested namespaces and well known top-level namespaces.
12. Enumerator Names
Enumerators (for both scoped and unscoped enums) should be named either like constants or like macros: either kEnumName or ENUM_NAME
13. Macro Names
In general macros should not be used. However, if they are absolutely needed, then they should be named with all capitals and underscores.
14. Exceptions to Naming Rules
15. Comment Style
16. File Comments
Start each file with license boilerplate.
17. Class Comments
Every non-obvious class declaration should have an accompanying comment that describes what it is for and how it should be used.
18. Function Comments
Declaration comments describe use of the function; comments at the definition of a function describe operation.
19. Variable Comments
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 requierd.
20. Implementation Comments
In your implementation you should have comments in tricky, non-obvious, interesting, or important parts of your code.
21. Punctuation, Spelling and Grammer
22. TODO Comments
Use TODO comments for code that is temporary, a short-term solution, or good-enough but not perfect.
23. Deprecation Comments
24. Line Length
Each line of text in your code should be at most 80 characters long.
25. Non-ASCII Characters
Non-ASCII characters should be rare, and must use UTF-8 formatting.
What is UTF-8 formatting?
26. Spaces vs. Tabs
Use only spaces, and indent 2 spaces at a time.
27. Function Declaration and Definitions
Return type on the same line as function name, parameters on the same line if they fit. Wrap parameter lists which do not fit on a single line as you would wrap arguments in a function call.
28. Lambda Expressions
Format parameters and bodies as for any other function, and capture lists like other comma-separated lists.
29. Function Calls
Either write the call all on a single line, wrap the arguments at the parenthesis, or start the arguments on a new line indented by four spaces and continue at that 4 spaces indent. In the absence of other considerations, use the minimum number of lines, including placing multiple arguments on each line where appropriate.
30. Braced Initializer List Format
Format a braced initializer list exactly like you would format a function call in its place.
31. Conditionals
Prefer no spaces inside parenthesis. The if and else keywords belong on separate lines.
32. 0 and nullprt/NULL
Use 0 for integers, 0.0 for reals, nullptr for pointers, and '\0' for chars.
33. sizeof
Prefer sizeof(varname) to sizeof(type)
