Google C++ Code Style

Header Files1. Define functions inline only when they are small, say, 10 lines or less2. When defining a function, parameter order is: inputs, then outputs3. Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries'

.h

,
your project's

.h

.Scoping1. Do not use a using-directive2. Place a function's variables in the narrowest scope possible, and initialize variables in the declarationStatic 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.Classes1. Use
the C++ keyword

explicit

for constructors with one argument2.
Composition is often more appropriate than inheritance. When using inheritance, make it

public

3. Do not overload operators except in rare, special circumstances4. 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)

.NamingThe 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.CommentsThough 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!FormattingCoding 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.