Google C++ Style Guide Summary

I put this together for some students and I thought it would be interesting to others.

A code style guide is a guide to what your source code should look like. It defines the appearance of the source code. It's important that you format your source code according to the style guide suggested by the project. 

The Google C++ coding style has become very popular. The Google style guide is rather large so I extracted some highlights below.

Tabs Versus Spaces: Use only spaces, and indent 2 spaces at a time (https://www.youtube.com/watch?v=SsoOG6ZeyUI).

File Names: Filenames should be all lowercase and can include underscores (_) or dashes (-). Follow the convention that your project uses. If there is no consistent local pattern to follow, prefer "_".

Extensions:  source.cc, header.h

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

Function length: Prefer small and focused functions.

Efficiency: Use ++i as opposed to i++. (https://medium.com/better-programming/stop-using-i-in-your-loops-1f906520d548)

Integers: <cstdint> defines types like int16_t, uint32_t, int64_t, etc. You should always use those in preference to short, unsigned long long and the like, when you need a guarantee on the size of an integer. Of the C integer types, only int should be used. 

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. For instance: a_local_variable, a_struct_data_member,a_class_data_member_.

Function Names: Ordinarily, functions should start with a capital letter and have a capital letter for each new word.

Comments:

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 maybe you!

Almost every function declaration should have comments immediately preceding it that describe what the function does and how to use it. 

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

Function Calls: If the arguments do not all fit on one line, they should be broken up into multiple lines, with each subsequent line aligned with the first argument. Do not add spaces after the open paren or before the close paren:

Use of spaces: 

if (condition) {               // Proper use of spaces
x = *p;
p = &x;
x = r.y;
x = r->y;
// Assignment operators always have spaces around them.
x = 0;

// Other binary operators usually have spaces around them, but it's
// OK to remove spaces around factors.  Parentheses should have no
// internal padding.
v = w * x + y / z;
v = w*x + y/z;
v = w * (x + z);

// No spaces separating unary operators and their arguments.
x = -5;
++x;
if (x && !y)
Return Values: Do not needlessly surround the return expression with parentheses.