Google C++ Code Style

Header Files

1. Define functions inline only when they are small, say, 10 lines or less

2. When defining a function, parameter order is: inputs, then outputs

3. Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your project's .h.

Scoping

1. Do not use a using-directive

2. Place a function's variables in the narrowest scope possible, and initialize variables in the declaration

Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction. However, such variables are allowed if they are constexpr: they have no dynamic initialization or destruction.

Classes

1. Use the C++ keyword explicit for constructors with one argument

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

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

4. Make data members private




Other C++ features

1. All parameters passed by reference must be labeled const. // OK, I doubt that...

2. 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.

3. We do not allow default function parameters, except in limited situations as explained below. Simulate them with function overloading instead, if appropriate.

4. We do not allow variable-length arrays or alloca().

5. We allow use of friend classes and functions, within reason.

6. We do not use C++ exceptions.

7. Avoid using Run Time Type Information (RTTI).

8. Use C++ casts like static_cast<>(). Do not use other cast formats like int y = (int)x; or int y = int(x);.

9. Use streams only for logging.

10. For simple scalar (non-object) values there is no reason to prefer one form and we allow either. For iterators and other template types, use pre-increment.

11. Use const whenever it makes sense. With C++11, constexpr is a better choice for some uses of const.

12. Be very cautious with macros. Prefer inline functions, enums, and const variables to macros.

The following usage pattern will avoid many problems with macros; if you use macros, follow it whenever possible:

• Don't define macros in a .h file.
• #define macros right before you use them, and #undef them right after.
• Do not just #undef an existing macro before replacing it with your own; instead, pick a name that's likely to be unique.
• Try not to use macros that expand to unbalanced C++ constructs, or at least document that behavior well.
• Prefer not using ## to generate function/class/variable names.

13. Prefer sizeof(varname) to sizeof(type).

Naming

The most important consistency rules are those that govern naming. The style of a name immediately informs us what sort of thing the named entity is: a type, a variable, a function, a constant, a macro, etc., without requiring us to search for the declaration of that entity. The pattern-matching engine in our brains relies a great deal on these naming rules.

Naming rules are pretty arbitrary, but we feel that consistency is more important than individual preferences in this area, so regardless of whether you find them sensible or not, the rules are the rules.

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

Comments

Though a pain to write, comments are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments.

When writing your comments, write for your audience: the next contributor who will need to understand your code. Be generous — the next one may be you!

Formatting

Coding style and formatting are pretty arbitrary, but a project is much easier to follow if everyone uses the same style. Individuals may not agree with every aspect of the formatting rules, and some of the rules may take some getting used to, but it is important that all project contributors follow the style rules so that they can all read and understand everyone's code easily.

Minimize use of vertical whitespace.