0. 扉页¶
| 版本: | 0.1 |
|---|---|
| 原作者: | Benjy Weinberger
Craig Silverstein
Gregory Eitzmann
Mark Mentovai
Tashana Landray
|
| 原翻译: | |
| 项目主页: |
0.1 现译者前言¶
非常感谢前人对中文翻译版的贡献，本人只是对其进行了一定的更新，主要目的是为了学习.
0.2 背景¶
C++ 是 Google 大部分开源项目的主要编程语言. 正如每个 C++ 程序员都知道的, C++ 有很多强大的特性, 但这种强大不可避免的导致它走向复杂，使代码更容易产生 bug, 难以阅读和维护.
本指南的目的是通过详细阐述在编写 C++ 代码时应该注意的事项来使得其复杂性得以控制. 这些规则在保证代码易于管理的同时, 也能高效使用 C++ 的语言特性.
风格, 亦被称作可读性, 也就是指导 C++ 编程的约定. 使用术语 “风格” 有些用词不当, 因为这些约定不仅涵盖源文件格式，还涉及更多内容.
Google开发的大多数开源项目都符合本指南的要求.
请注意，本指南不是C ++教程：我们假定读者已经熟悉该语言.
0.3 风格指南的目标¶
为什么会有这份文件？
我们认为本指南应达到一些核心目标.这些目标是产生下列规则的原因. 通过提出这些想法，我们希望能够进行讨论并让社区能够更清楚为什么制定了规则以及每个选择的理由. 如果您了解每个规则所服务的目标，则应该让所有人知道什么时候可以不使用某条规则，以及在指南中更改规则所需的条件.
我们目前设定的风格指南的目标如下：
风格规则应发挥作用
风格规则的好处必须足够大，足以让我们所有的工程师记住它.应用风格的收益是从我们将获得的代码库进行衡量的，因此，如果人们无论如何都不愿意这样做，那么非常有害的实践可能仍然会产生很小的收益.该原则主要说明了我们不使用的规则，而不是我们已经使用的规则：例如，goto违反了以下许多原则，但是现在已经很少消失了，因此风格指南不再讨论.
针对阅读而非写作进行优化
我们的代码库（以及提交给它的大多数单个组件）预计将持续相当长的一段时间.因此，与编写代码相比，花费在阅读大多数代码上的时间更多.我们明确选择针对普通软件工程师在代码库中读取，维护和调试代码的体验进行优化，而不是在为了编写所述代码时轻松. “为读者留下痕迹”是该原理的一个特别常见的子要点：当一段代码中发生了令人惊讶或异常的事情时（例如，指针所有权的转移），此时，给读者留下一段文本提示将非常有价值（std::unique_ptr在使用时明确表面了所有权转移）.
与现有代码保持一致
在我们的代码库中一致地使用同一种样式，使我们可以专注于其他（更重要的）问题。一致性还可以实现自动化：自动化工具在格式化代码或者调整 #includes时，只有在代码与工具的期望一致时才能正常工作。在许多情况下，使用“保持一致”的规则可以归结为“之选择一个而不再东张西望”。在这些问题上允许灵活性的潜在价值被人为争论的成本所抵消。
在适当的时候与更广泛的C ++社区保持一致
与其他组织使用C ++的方式保持一致具有价值，其原因与我们代码库中的保持一致相同。如果C ++标准中的某个功能解决了一个问题，或者某个惯用语已广为人知并被接受，那么这就是使用它的理由。但是，有时标准功能和习惯用法有缺陷，或者只是在设计时就没有考虑我们的代码库的需求。在这种情况下（如下所述），限制或禁止标准功能是合适的。在某些情况下，出于感知上的优势或价值不足以将代码库转换为标准接口的原因，我们更喜欢使用本地库或第三方库，而不是C ++标准中定义的库。
避免令人惊讶或危险的构造 C ++具有比人们一眼就能想到更令人惊讶或危险的功能。一些样式指南使用限制避免陷入这些陷阱。对于这样的限制，放弃样式指南的条件很高，因为放弃这样的规则通常会直接损害程序的正确性。
避免使用普通C ++程序员感到棘手或难以维护的结构
由于C ++引入代码的复杂性，因此C ++具有通常可能不合适的功能。在广泛使用的代码中，使用更具技巧性的语言构造可能会更容易接受，因为更复杂的实现所带来的任何好处都会因使用而倍增，并且在使用复杂的语言部分时无需再次付出理解复杂性的代价。如对此有疑问，可以通过询问您的项目负责人寻求豁免此类规则。这对于我们的代码库特别重要，因为代码所有权和团队成员关系会随着时间而变化：即使目前使用某段代码的每个人都可以理解，但仍不能保证这种理解会持续几年。
注意我们的规模
对于拥有超过一亿行代码库和数千名工程师的代码库来说，一位工程师产生的一些错误和简化可能会使许多人付出高昂的代价。例如，避免污染全局命名空间尤为重要：如果每个人都将其代码放入全局名称空间，则对于亿万行代码库中的命名空间来说冲突很难避免并且很难处理。
必要时考虑进行优化
性能优化有时可能是必要且适当的，即使它们与本文档的其他原则相冲突。
本文档的目的是在合理的限制下提供最大的指导。与往常一样，常识和良好品味应占上风。在此，我们特别参考了整个Google C ++社区的既定惯例，而不仅仅是您的个人喜好或团队的个人喜好。持怀疑态度，不使用聪明或不寻常的构造：没有禁止不等于许可。使用您的判断，如果不确定，请不要犹豫，询问您的项目负责人。
0.4 C++ 版本¶
目前，代码应使用C++17，也就是不应使用C ++ 2x的功能。随着时间的推移，本指南所针对的C ++版本将（积极地）前进。
不要使用非标准扩展名。
在项目中使用C ++ 14和C ++ 17中的功能之前，请考虑其他环境的可移植性。