原则

为读者而非写者优化

代码库通常具有较长的生命周期，阅读代码所花的时间远多于编写代码。我们明确选择为阅读、维护和调试代码库中代码的普通软件工程师的体验进行优化，而非为编写代码的便利性。例如，当代码片段中发生了意外或不寻常的事情时，为读者留下文字提示是很有价值的。

保持一致

当风格指南允许多种选项时，最好选择一种选项而不是混合使用多种选项。在整个代码库中一致地使用一种风格可以让工程师专注于其他（更重要的）问题。一致性还能实现更好的自动化，因为一致的代码允许更高效地开发和运行格式化或重构代码的工具。在许多情况下，归因于”保持一致”的规则归结为”选一个然后不要再纠结”；在这些方面允许灵活性的潜在价值被人们为此争论的成本所抵消。

与 Apple SDK 保持一致

与 Apple SDK 使用 Objective-C 的方式保持一致，其价值与我们代码库内部保持一致的原因相同。如果 Objective-C 的某个特性能解决问题，那就是使用它的理由。然而，有时语言特性和惯用法是有缺陷的，或者是基于非通用的假设设计的。在这些情况下，约束或禁止语言特性或惯用法是合适的。

风格规则应当物有所值

风格规则的收益必须足够大，才值得要求工程师记住它。收益是相对于没有该规则时我们会得到的代码库来衡量的，因此针对非常有害的做法的规则如果人们本来就不太可能这样做，那它的收益可能仍然很小。这一原则主要解释了我们没有的规则，而不是我们有的规则：例如，goto 违反了以下许多原则，但由于极其罕见而未被讨论。