Google C++ Style Guide

原文地址：https://google.github.io/styleguide/cppguide.html

背景

        C++ 是 Google 众多开源项目所使用的主要开发语言之一。正如每一位 C++ 程序员所知，这门语言拥有许多强大的特性，但这份强大同时也带来了复杂性，而复杂性进而可能导致代码更容易出现缺陷，并且更难阅读和维护。

        本指南的目标是通过详细描述编写 C++ 代码时的最佳实践与禁忌，来管控这种复杂性。制定这些规则是为了在保持代码库可管理性的同时，仍允许开发者有效地利用 C++ 的语言特性。

        代码风格（Style），我们也称之为可读性，是指支配我们 C++ 代码的那些约定。虽然名为“风格”，但这其实是一个不太准确的术语，因为这些约定所涵盖的范围远不止源文件的格式化。

        Google 开发的大多数开源项目都遵循本指南中的要求。

        请注意，本指南并非 C++ 教程：我们假定读者已经熟悉该语言。

风格指南的目标

        为什么要编写这份文档？

        我们认为本指南应服务于几个核心目标。这些是支撑所有具体规则的根本原因。通过将这些理念摆在台面上，我们希望能让讨论更有依据，并让更广泛的社区更清楚地理解：为什么要有这些规则，以及为什么做出了特定的决策。如果您理解了每条规则所服务的目标，那么当遇到可以破例（有些规则确实可以）的情况时，或者当您需要提出何种论据或替代方案来修改指南中的规则时，一切就会变得清晰明了。

        我们目前所看到的风格指南的目标如下：

        1. 风格规则应当“物有所值”
        一条风格规则带来的好处必须足够大，大到值得让所有工程师去记忆它。这种好处是相对于“没有这条规则时我们的代码库状况”来衡量的。因此，即使是一条针对非常有害实践的规则，如果大家本来就不大可能犯这个错误，那它的价值也是很小的。这一原则主要解释了我们没有制定某些规则的原因，而非我们制定了哪些规则。

例如：goto 语句违背了下面许多原则，但它在现代 C++ 中已经几乎绝迹，所以风格指南中不再专门讨论它。

        2. 优化阅读体验，而非编写体验
        我们的代码库（以及提交到其中的大多数独立组件）预计会存在相当长的时间。因此，阅读我们大部分代码所花费的时间将远远超过编写它的时间。我们明确选择：优化我们普通软件工程师在阅读、维护和调试代码库时的体验，而不是为了编写代码时的一时方便。

“为读者留痕” 是这一原则的一个常见具体体现：当代码片段中发生了一些令人意外或不寻常的事情时（例如指针所有权的转移），在使用点为读者留下文本提示是非常有价值的（例如 std::unique_ptr 在调用点就明确无误地展示了所有权的转移）。

        3. 与现有代码保持一致
        在整个代码库中始终如一地使用一种风格，能让我们专注于其他（更重要的）问题。一致性也使得自动化成为可能：那些格式化代码或调整 #include 的工具，只有在你的代码符合其预期时才能正常工作。
        在许多情况下，归因于“保持一致”的规则归结起来就是“随便选一个，然后别再纠结了”；在这些点上允许灵活性的潜在价值，往往被人们为此争论的成本所抵消。
        但是，一致性是有界限的：它在没有明确技术论据，也没有长期方向时是一个很好的“决胜局”手段。它在局部（每个文件，或一组紧密相关的接口）中适用性更强。一致性通常不应被用作“不考虑新风格的好处，或者无视代码库随时间推移倾向于收敛到新风格的趋势，而坚持旧风格”的理由。

        4. 在适当情况下，与更广泛的 C++ 社区保持一致
        与其他组织使用 C++ 的方式保持一致，其价值与在我们代码库内部保持一致的价值相同。如果 C++ 标准中的某个特性解决了问题，或者某种惯用法被广泛知晓和接受，那就是使用它的理由。
        然而，有时标准特性或惯用法是有缺陷的，或者在设计时没有考虑到我们代码库的需求。在这种情况下（如下所述），限制或禁止标准特性是适当的。在某些情况下，我们更倾向于使用自研或第三方库，而不是 C++ 标准定义的库，原因要么是前者被认为更优越，要么是迁移到标准接口的价值不足以抵消成本。

        5. 避免令人意外或危险的构造
        C++ 有一些特性，乍一看可能比想象中更令人意外或危险。风格指南中的一些限制就是为了防止掉入这些陷阱。对于此类限制，破例的门槛非常高，因为打破这些规则往往会直接危及程序的正确性。

        6. 避免我们的普通 C++ 程序员会觉得棘手或难以维护的构造
        C++ 有一些特性可能并不适合普遍使用，因为它们会给代码引入复杂性。在被广泛使用的代码中，使用更复杂的语言构造可能是可以接受的，因为更复杂的实现所带来的任何好处，都会因其广泛的使用而被放大；而当处理代码库的新部分时，理解这种复杂性的成本不需要再次支付。

当您不确定时，可以通过询问您的项目负责人来寻求此类规则的豁免。这一点对我们的代码库尤为重要，因为代码的所有权和团队成员资格会随着时间而变化：即使目前所有处理某段代码的人都理解它，也无法保证几年后这种理解依然存在。

        7. 考虑到我们的规模
        考虑到我们的代码库规模（上亿行）和工程师数量（数千人），某些对单个工程师来说的简化或错误，对许多人来说都会变成高昂的成本。

例如：避免污染全局命名空间就显得尤为重要。在数亿行代码的规模下，如果每个人都把东西放到全局命名空间，产生的命名冲突将非常难以处理且难以避免。

        8. 在必要时，向性能优化妥协
        有时性能优化可能是必要且适当的，即使它们与本文档的其他原则相冲突。

        本文档旨在在施加合理限制的同时，提供最大程度的指导。一如既往，常识和良好的品味应占据主导地位。我们这里具体指的是整个 Google C++ 社区公认的惯例，而不仅仅是您个人或您团队的偏好。对使用巧妙或不寻常的构造应持怀疑态度，并尽量避免：没有明令禁止并不等同于允许使用。请运用您的判断力，如果您不确定，请毫不犹豫地向您的项目负责人寻求额外的意见。