CHAPTER 8 Style Guides and Rules

代码风格指南和规则

大多数工程组织都有管理其代码库的规则--关于源文件存储位置的规则，关于代码格式的规则，关于命名和模式以及异常和线程的规则。大多数软件工程师都在一套控制他们如何操作的政策范围内工作。在谷歌，为了管理我们的代码库，我们维护了一套风格指南来定义我们的规则。

规则就是法律。它们不只是建议或推荐，而是严格的、强制性的法律。因此，它们是普遍可执行的--除非在需要使用的基础上被批准，否则规则不能被忽视。与规则相反，指南提供了建议和最佳实践。这些位是好的，甚至是非常值得遵循的，但与规则不同的是，它们通常有一些变化的空间。

我们把我们定义的规则，即写代码必须遵守的 "做"和 "不做"，收集在我们的编程风格指南中，这些指南被视为典范。"风格"在这里可能有点名不副实，意味着一个仅限于格式化做法的集合。我们的风格指南不仅仅是这样；它们是管理我们代码的一整套惯例。这并不是说我们的风格指南是严格的规定性的；风格指南的规则可能需要判断，例如使用 "在合理范围内尽可能描述"的名称的规则。相反，我们的风格指南是对我们的工程师负责的规则的最终来源。

我们为谷歌使用的每一种编程语言制定了单独的风格指南。在高层次上，所有的指南都有类似的目标，旨在引导代码开发，并着眼于可持续性。同时，它们之间在范围、长度和内容上也有很大的差异。编程语言有不同的优势，不同的特点，不同的优先级，以及在谷歌不断发展的代码库中采用的不同历史路径。因此，独立定制每种语言的指南要实际得多。我们的一些风格指南是简洁的，专注于一些总体原则，如命名和格式化，正如我们的Dart、R和Shell指南所展示的。其他的风格指南包括更多的细节，深入研究特定的语言特征，并延伸到更长的文件中--特别是我们的C++、Python和Java指南。一些风格指南重视语言的典型非Google使用--我们的Go风格指南非常简短，只在一个摘要指令中增加了一些规则，以遵守外部认可的惯例。其他的规则包括从根本上不同于外部规范的规则；我们的C++规则不允许使用异常，这是一个在Google代码之外广泛使用的语言特性。

即使是我们自己的风格指南也有很大的差异，这使得我们很难准确地描述一个风格指南应该包括什么。指导谷歌风格指南发展的决定源于保持我们代码库可持续发展的需要。其他组织的代码库对可持续发展有不同的要求，因此需要一套不同的定制规则。本章主要从Google的C++、Python和Java风格指南中抽取例子，讨论指导我们制定规则和指南的原则和过程。

为什么有规则？

那么，我们为什么要制定规则？制定规则的目的是为了鼓励 "好"的行为，阻止 "坏"的行为。对 "好"和 "坏"的解释因组织而异，取决于该组织所关心的问题。这种指定不是普遍的偏好；好与坏是主观的，并根据需要而定。对于一些组织来说，"好"可能会促进支持小内存足迹的使用模式，或优先考虑潜在的运行时优化。在其他组织中，"好"可能会促进行使新语言功能的选择。有时，一个组织最关心的是一致性，所以任何与现有模式不一致的东西都是 "坏的"。我们必须首先认识到一个特定的组织所重视的东西；我们使用规则和指导来鼓励和阻止相应的行为。

随着一个组织的成长，既定的规则和指南塑造了编码的共同词汇。一个共同的词汇允许工程师专注于他们的代码需要说什么，而不是他们如何说。通过塑造这种词汇，工程师会倾向于做默认的 "好"事情，甚至是下意识的。因此，规则为我们提供了广泛的杠杆作用，使常见的开发模式朝着理想的方向发展。

创建规则

在定义一套规则时，关键问题不是 "我们应该有什么规则"？要问的问题是，"我们试图推进什么目标？" 当我们专注于规则所要服务的目标时，确定哪些规则支持这一目标，就会更容易提炼出一套有用的规则。在谷歌，风格指南作为编码实践的法律，我们不问："什么东西进入风格指南？"而是问："为什么一些东西进入风格指南？" 我们的组织通过拥有一套规范编写代码的规则获得了什么？

指导原则

让我们把事情放在背景中。谷歌的工程组织由超过3万名工程师组成。这些工程人员在技能和背景方面表现出极大的差异性。每天大约有60,000个项目提交到一个超过20亿行的代码库中，而这个代码库可能会存在几十年。我们正在优化一套不同于其他大多数组织需要的价值，但在某种程度上，这些问题是普遍存在的--我们需要维持一个对规模和时间都有弹性的工程环境。

在这种情况下，我们的规则的目标是管理我们的开发环境的复杂性，保持代码库的可管理性，同时仍然允许工程师有成效地工作。我们在这里做了一个权衡：帮助我们实现这一目标的大量规则意味着我们限制了选择。我们失去了一些灵活性，甚至可能会得罪一些人，但权威的标准所带来的一致性和减少冲突的好处是最重要的。

鉴于这种观点，我们认识到一些指导我们规则发展的总体原则，这些原则必须：