Each style point has a summary for which additional information is available by toggling the accompanying arrow button that looks this way: ▶. You may toggle all summaries with the big arrow button:

Important Note 重要的注释 （下面的翻译，尽量做到忠实原文，但是由于水平有限有限无法做到“信，达，雅”。有些翻译更多是本着“信”的原则，谅解）

Background 背景知识

C++ is the main development language used by many of Google’s open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain.

Google的许多开源项目使用C++作为开发语言。每一个C++程序员均知道：正如一把双刃剑，一方面其提供了许多强大的特性（例如：多态，继承等），另一个方面正是这些强大的特性给程序开发人员带来了无以比拟的复杂性。 这也导致了使用C++编写的项目更加容易出现错误，难以维护等缺点。

PS:诚如许多软件工程师所说那样：也许项目中的bug多寡以及是否易于维护与所采用的语言无多少联系，但一个易于理解，易于使用的工具总会减少我们犯错的机会。一个越复杂的工具，越是容易导致错误， 除非自己对该工具是特别的熟悉且在使用的过程中也特别的小心。因此，一个良好的风格和一个良好的设计就显得格外重要。而此编程风格便是由google众多高手所采用的且在许多项目中得到广泛的采用。

The goal of this guide is to manage this complexity by describing in detail the dos and don’ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.

该指导的目的是通过详细阐述在使用C++编程时哪些是值得提倡的做法、哪些是不值得提倡的做法来降低由于其复杂性所带来的那些缺点（难以维护，易于产生错误）。 这些规则保证了你在高效的使用C++的那些特性的同时能够保证代码具有一定的可维护性。

Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.

风格，有时候也被称作可读性。其是我们在编写C++程序时所采用且保持的一些惯例。 对于术语“风格”的使用肯能有些用词不当，因为这些惯例不单单仅是源文件所采用那种格式那么简单。

One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another’s code and quickly understand it. Maintaining a uniform style and following conventions means that we canp more easily use “pattern-matching” to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.

我们用强制的一致性来保证我们的基代码具有一定的可维护性。其对于其他开发人员来说非常重要， 因为该一致性能够保证可以很快的看懂并理解其他开发人员编写的代码。 维护统一的风格并遵循一定的规则意味着我们可以很容易的使用“模式匹配”来推断变量所代表的含义、哪些常量为真。 共识、术语以及模式这些有助于我们理解代码。在某些情况下，可以有更好的借口来更换已形成的风格，但是为了保证编码的一致性我们仍然要保留这些风格。

Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.

本指南涉及的另一个问题是，C + +特性膨胀。C + +是一个有很多高级特性的庞大语言。 在某些特定的情况下，我们限制，甚至禁止某些使用某些特性。我们这么做事为了保证代码的 简洁和避免由此特性所带来的一些不同的常规错误。该指南列出了这些特性并详细的解释了我们为什么限制使用这些特性。

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.

备注：本指南不是C++说明：我们假设你是较为熟练的掌握该门语言。

Header Files 头文件

In general, every .cc file should have an associated .h file. There are some common exceptions, such as unittests and small .cc files containing just a main() function.

通常，每个.cc文件都应有一个与其相关联的.h文件。 但也有例外的情况，例如一些单元测试、仅包含main()函数的小规模.cc文件。

Correct use of header files can make a huge difference to the readability, size and performance of your code.

正确的使用头文件对着代码的可读性、代码的大小和代码的性能有着巨大的影响。

The following rules will guide you through the various pitfalls of using header files.

下面的规则帮助你在使用头文件的过程中穿过荆棘丛生的那些陷阱。

Scoping

Classes

Classes are the fundamental unit of code in C++. Naturally, we use them extensively. This section lists the main dos and don’ts you should follow when writing a class.

Google-Specific Magic

There are various tricks and utilities that we use to make C++ code more robust, and various ways we use C++ that may differ from what you see elsewhere.

Other C++ Features

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.

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.

To help you format code correctly, we’ve created a settings file for emacs.

Exceptions to the Rules

The coding conventions described above are mandatory. However, like all good rules, these sometimes have exceptions, which we discuss here.