5
Most open-source projects developed by Google conform to the requirements in this guide.
Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.
Goals of the Style Guide
Why do we have this document?
There are a few core goals that we believe this guide should serve. These are the
fundamental whys that underlie all of the individual rules. By bringing these ideas to the fore, we
hope to ground discussions and make it clearer to our broader community why the rules are in
place and why particular decisions have been made. If you understand what goals each rule is
serving, it should be clearer to everyone when a rule may be waived (some can be), and what sort
of argument or alternative would be necessary to change a rule in the guide.
The goals of the style guide as we currently see them are as follows:
Style rules should pull their weight
The benefit of a style rule must be large enough to justify asking all of our engineers to
remember it. The benefit is measured relative to the codebase we would get without the rule,
so a rule against a very harmful practice may still have a small benefit if people are unlikely
to do it anyway. This principle mostly explains the rules we don’t have, rather than the rules
we do: for example, goto contravenes many of the following principles, but is already
vanishingly rare, so the Style Guide doesn’t discuss it.
Optimize for the reader, not the writer
Our codebase (and most individual components submitted to it) is expected to continue for
quite some time. As a result, more time will be spent reading most of our code than writing it.
We explicitly choose to optimize for the experience of our average software engineer
reading, maintaining, and debugging code in our codebase rather than ease when writing
said code. "Leave a trace for the reader" is a particularly common sub-point of this principle:
When something surprising or unusual is happening in a snippet of code (for example,
transfer of pointer ownership), leaving textual hints for the reader at the point of use is
valuable (std::unique_ptr demonstrates the ownership transfer unambiguously at the call
site).
Be consistent with existing code
Using one style consistently through our codebase lets us focus on other (more important)
issues. Consistency also allows for automation: tools that format your code or adjust
your #includes only work properly when your code is consistent with the expectations of the
tooling. In many cases, rules that are attributed to "Be Consistent" boil down to "Just pick