为什么鲍勃叔叔建议如果可以避免的话，不应该写下编码标准？

当我阅读此问题时，投票得最高的答案引用了Bob叔叔的编码标准，但这个提示使我感到困惑：

3. 如果可以避免，请不要写下来。相反，让代码成为捕获标准的方式。

这在我的大脑中反弹，但是我找不到合适的地方。如果有新成员加入团队，或者编码标准发生了变化，信息会不会混乱？

我为什么不应该写下编码标准？

有几个原因。

1. 没有人阅读文档。
2. 即使阅读了文档，也没有人遵循该文档。
3. 即使阅读并遵循了文档，也没有人更新文档。
4. 写一份实践清单远没有创造一种文化有效。

编码标准不是关于人们应该做什么，而是关于他们实际应该做什么。当人们偏离标准时，应通过代码审查过程和/或自动化工具来进行选择和更改。

请记住，编码标准的全部目的是使我们的生活更轻松。它们是我们大脑的捷径，因此我们可以从重要内容中过滤出必要的内容。与实施正式文档相比，创建一种强制执行此审核的文化要好得多。

还有另一种解释。我不相信这是鲍伯叔叔的意思，但值得考虑。

不要捕获文档中的编码标准。通过具有验证符合标准的自动化过程，以代码形式捕获它。

不要依赖人们引用文档，但是同时，不要依赖人们解释已经存在的代码并确定约定和巧合。

将Checkstyle之类的内容合并到您的提交版本中。这可以强制执行诸如格式化和命名标准之类的基本规则，而不是花精力在考虑样式上，而所有这些都可以卸载到一个愚蠢的过程中，这至少可以保证是彻底的。

如果很重要，则严格定义所需的内容，如果错误则失败。

人们忽视了编码标准文档的真正目的，即解决争端。

编码标准中的大多数决定只会对可读性和生产率产生很小的影响。特别是如果您对语言采用“常规”风格，并且语言设计师开始意识到这应该成为规范的一部分（例如Go）。

因为它们是如此琐碎，所以争论会变得很热烈，并且持续不断，严重损害生产力和团队凝聚力。或者可以通过在两个或多个人的首选样式之间进行无休止的重新格式化来掩盖您的变更历史。

制定书面标准就结束了争论。管理者可以指出这一点，并转移对文档的不满。您可以用一张纸争论，但它不会听您的。

（另请参见无结构性的暴政）

因为评论是谎言。

编码标准对代码应该是什么有很大的帮助。代码本身就是真理的最终来源。在这种情况下，真理不是代码行为，而是它所表达的样式。如果您的标准尚未反映在代码中，那么您还有很多工作要做。

鲍勃叔叔认为注释是程序员的个人失败，因为它证明他没有设法用编程语言本身来表达代码片段的目的。类似地，标准文档无法在代码库中表达连贯的风格。

新程序员应该花时间看代码，而不是花几天时间阅读多章的标准文档（叹息，我不得不这样做）。

标准文档并不是一个坏主意，但是我去过编程商店，维护标准文档是某人的全职工作。请，如果您必须保留标准文档，请保留在页面上。但是，如果您已经有了代码，难道没有人能在不到一天的时间内将同一文档放在一起吗？

制定代码标准很重要。拥有说明其含义的文档不是。

为什么鲍勃叔叔建议如果可以避免的话，不应该写下编码标准？

如果您要问他的意见背后的原因，那么只有他将在此处发布答案（我们的意见无关紧要），您才能得到答案。

我为什么不应该写下编码标准？

如果您要问他是否正确：让我成为到目前为止（唯一）不受欢迎的人，说您没有理由避免这样做。

写下来。但是我会尽力解释我的原因...

戴维（David）在评论中建议，斯蒂芬（Stephen）回答的重点不是为什么您不应该编写文档，而是文档的形式。如果指南已在工具中正式化（不仅仅是手工代码审查），那么我可能会同意（法律不需要其他内容时）。请注意，不幸的是，工具通常无法检查所有内容（计算理论不是我们的朋友），因为它们仅限于特定的翻译单元或程序包或您喜欢的语言称为boundary的任何语言。

但是鲍伯叔叔的措辞并没有使我认为他在谈论那件事。

我可以不同意这样的高级专家吗？对于引用的帖子中的几乎所有内容，我都会这样做（有关详细信息，另请参见此答案的第二部分）。让我们尝试了解原因（假设您已经知道编码准则不仅仅涉及较小的格式问题）。

• 在某些情况下，法律需要书面编码标准。
• 我确实阅读过文档，但我肯定并不孤单。团队成员可能会随着时间而变化，知识不会存在于5-10年的代码库中或团队成员的头脑中。组织应解雇不遵守内部准则的人员。
• 编码标准一旦获得批准，就不会经常更改，如果您想知道，也可以更改。如果标准更改，则您的文档（以代码形式）已过时，因为您的所有代码均未遵循新标准。重新格式化/重构可能会很慢，但是您始终要遵循书面权威指南。
• 最好阅读5页的文档，而不是检查10 / 20K LOC以推断规则（顺便说一句，您可能会误解），这是毫无疑问的。
• 具有讽刺意味的是，曾经写过许多有关设计原理和编码风格的书的人建议你不要写自己的指南，如果他给我们扔一些代码示例，岂不是更好吗？不，因为书面指南不仅会告诉您该怎么做，而且还会告诉您代码缺少的其他两件事：不做什么和不这样做的原因。

“免费的自组织编程”对16岁的忍者有好处，但组织还有其他要求：

• 必须在公司一级授予（定义）代码质量-这不是一个团队可以决定的事情。他们甚至可能没有能力决定更好的方法（例如，有多少开发人员具备审查MISRA或什至仅了解每条规则的全部必要技能？）
• 成员可以在不同的团队中移动：如果每个人都遵循相同的编码标准，则集成是平稳的，并且不易出错。
• 如果团队是自我组织的，那么随着团队成员的变化，这些标准将随着时间的推移而不断发展-您将拥有一个庞大的代码库，不遵循当前公认的标准。

如果您在流程之前就在考虑人，那么我只能建议您阅读TPS：人类是精益的核心部分，但是程序是高度正规的。

当然，只有一个团队的小型组织可以让团队决定采用的标准，但是必须将其写下来。您可以在Programmers.SE上阅读Eric Lippert的帖子：我想我们都同意他是一位经验丰富的开发人员，当他在Microsoft工作时，他必须遵守他们的书面准则（即使某些规则可能是错误的，不适用的或无用的）给他。）乔恩·斯基特（Jon Skeet）呢？Google准则非常严格（许多人不同意），但他必须遵守这些准则。对他们不尊重吗？不，他们可能会努力定义和改进此类准则，一家公司不是由一个成员（或一个团队）组成，每个团队也不是孤岛。

例子

• 您决定不使用C ++中的多个继承和嵌套类，因为您的实际团队成员对此不太了解。后来，想要使用多重继承的人必须浏览整个1M LOC，以查看它是否曾经被使用过。这很糟糕，因为如果没有记录设计决策，则必须学习整个代码库才能理解它们。即使到那时，如果还没有使用它，那是因为它违反了编码标准，还是被允许使用，但是在任何较早的情况下，多重继承都不是一个合适的选择吗？
• 在C＃中，您有重载的方法来提供默认参数，因为当C＃中没有可选参数时，您的代码库就会启动。然后，您进行了更改并开始使用它们（重构旧代码以在每次必须修改此类功能时使用它们）。甚至在以后，您仍然认为可选参数不好，因此开始避免使用它们。什么是规则，你的代码告诉你吗？这很不好，因为标准在发展，但是代码库在发展却很慢，如果是您的文档，那么您就麻烦了。
• 乔恩从团队A移动到B队乔恩必须学习的新标准; 在学习过程中，他可能会引入更多细微的错误（或者，如果幸运的话，花很长时间来理解现有代码并延长代码审查时间）。
• 团队A移至团队B先前拥有的代码库。它具有完全不同的编码标准。改写？适应？混合？所有这些都同样糟糕。

鲍伯叔叔

让它们在前几次迭代中进化。

没错，直到您没有标准，并且您的组织已向您分配了构建标准的任务。

让他们特定于团队而不是特定于公司。

否，出于上述所有原因。即使您只是想将代码格式化形式化（这可能是您最不希望使用的形式化形式），我仍然怀念着无休止的（和无用的）关于格式化的战争。我不想一遍又一遍地生活，一劳永逸。

如果可以避免，请不要写下来。相反，让代码成为捕获标准的方式。

否，出于上述所有原因（当然，除非准则更改时您可以一次性重构所有代码）。您是否要按原样保留代码？您如何检查代码库以了解当前准则？按文件年龄进行搜索并使您的编码风格适应源文件年龄？

不要立法好的设计。（例如，不要告诉人们不要使用goto）

的确，准则必须简短，否则没人会阅读。不要重复显而易见的事情。

确保每个人都知道该标准与通信有关，而别无其他。

好的标准不仅与质量有关，除非您只希望对次要细节有标准。

经过最初的几次迭代后，请团队共同决定。

首先要了解的是，别忘了编码标准通常是一个需要花费很多年才能开发和完善的过程：迭代很少，也许是初级开发人员？真？您是否要依靠一位资深（如果有）成员的记忆？

三个注意事项：

• 我认为某些语言的弊端比其他语言更为严重，例如，在C ++中，与Java相比，甚至更需要公司级标准。
• 如果您在一家只有一个小团队的非常小的公司中工作，那么这种推理可能并不完全适用（鲍勃叔叔的原因可能不太极端）。
• 您被录用了（作为团队），您将单独处理一个新项目，然后您会忘记它并继续前进。在这种情况下，您可能不在乎（但您的雇主应该...）

1. 为使编码标准有用，不得谈论实质性问题；唯一的风格。它应该仅指定那些任意和模棱两可的事物。例如，支撑位置，缩进深度，空格与制表符，命名约定等。
2. 风格问题是本地问题，而不是全球问题。每个团队都应采用自己独特的风格，使其与任务和个性相匹配。这使标准保持简单和轻便。由于所有可能的考虑因素，配置和例外情况，公司标准变得不堪重负。
3. 在团队中，编写单独的编码样式文档的唯一原因是团队产生的代码是否不符合标准。在这种情况下，您没有标准。为了有效，该标准应由代码本身来表达。如果是这样，则无需单独的文件。
4. 在旧系统中，团队和样式会随着时间而变化。没有错。旧代码将具有较旧的样式。较新的代码将具有较新的样式。团队应该了解样式及其年龄。每当编写新代码时，无论代码位于代码中的何处，都应采用新样式。

我为什么不应该写下编码标准？

这件事情是由很多原因导致的。以下是一些注意事项：

1. 人们花多少时间花在“学习”代码标准上，才有很多时间花在整个团队上，以审查，讨论，记录，修改……等代码标准。这就像不断地讨论您的“员工手册”-将它多久发送一次团队会议的议程？

2. 当一个项目被退款/搁置/等时。那么留下来的少数人通常无法继续遵守（甚至可能没有阅读过）标准。您知道的第二件事，就是“保持代码干净”的所有工作几乎都被浪费了。

3. 如果项目停滞不前或引入了新的领导者，那么人们很可能会完全忽略以前的规则，并希望以一种新的方式来做。再次，编纂标准有什么收获？

您应该确保阅读＃6：

经过最初的几次迭代后，请团队共同决定。

换句话说，当需要启动一个项目时，请顺其自然。然后讨论当前团队正在使用的编码标准的一般规则-并基本遵循它们。这样，您可以最大程度地提高改进产品的工作量，同时又可以减少编写，查看和记录获取可执行代码所需的“语法糖”所需的工作量。

很少有团队从编码标准中获得巨大收益。通常，“可读性”过于模糊-大多数开发人员不会从间距，换行等方面的确切规则中受益匪浅，但是您可以通过至少设置一些规则来避免不断惹恼开发人员。

我认为不够明确的另一个答案是，这也意味着人们不会盲目遵守规则。这意味着人们必须为他们的设计决策和编码约定提供实际的理由，而不是仅仅依赖于已被记录下来以证明其合理性的事实。

首先，据我所知，鲍伯叔叔是Java人士，这对于理解他的话非常重要。

在Java或C＃团队中工作时，如果当前的代码是由经验丰富的开发人员编写的，那么我很容易掌握并保持编码风格。如果我不愿意这样做，也许我不是合适的人选。。。如果我不遵循样式，没有代码审查或结对编程来接我，那么该公司就会比我命名成员字段的方式更大的问题！

Java和C＃以及大多数现代语言都已定义，因此程序员很少会陷入“简单”陷阱。

但是，当我开始编程时，我正在使用C（以及后来的C ++）。在C中，您可以编写如下代码

if (a = 3);
{
   /* spend a long time debugging this */
}

编译器不会给出错误，并且在阅读大量代码时很难发现错误。但是，如果您写：

if (3 = a)
{
   /* looks odd, but makes sense */
}

编译器给出了一个错误，我很容易将代码更改为3 == a。同样，如果不允许=在if条件或“空if语句”中使用编码标准，则可以将代码检查器用作构建系统的一部分，以跟踪此错误。

当我离开C / C ++时，我对编码标准的看法发生了巨大的变化：我曾经喜欢严格执行的编码标准，而且页面长很多。我现在认为您只需要列出正在使用的工具，并在一些命名约定上让原始团队成员之间达成非正式协议。我们不再生活在由30多个使用C / C ++编写应用程序的开发人员组成的团队的世界中...

我从来不喜欢JScript是有原因的，并且认为TypeScript是多年来进行Web开发的最佳方式。我期望Web UI开发人员由于HTML / CSS / JScript等的设计缺陷而仍然需要编码标准。

将源作为自记录编码标准意味着两件事。

1. 人们必须查阅代码库并进行审查，才能成为熟练的贡献者。这是非常重要的。与深入研究代码库相比，阅读代码指南是浪费时间。
2. 它承认微小的差异并不重要。达成共识并了解基本原理很重要。保持一致的风格不是追求艺术的追求。它不允许无用的挑衅者惹恼和分散其他人的注意力。这是关于通过团队中的代码促进沟通。

经常更新且编写得很好的代码标准文档可能会非常有用，但是通常并非如此。标准文档不能反映公司使用的实际编码标准，因为创建好的标准文档非常困难，甚至很难保持最新。

最好没有任何文件，而让代码本身代表这些标准，而不是编写糟糕的和令人误解的编码标准文件。无论哪种方式，最重要的部分是在代码中应用标准，这不仅需要文档。动机，过程，培训，工具等更为重要。

尚未明确说明的一个非常重要的事情是，编码标准就像语言一样：它们在不断发展。书面的编码标准妨碍了这一工作，如果不是，它就会持续过时且无用。

没有明确的编码标准还不错。如果您在签入时进行同行评审，则每当有不符合编码标准的内容进入存储库时，这意味着有2个人对此进行了思考*，并决定此变更的好处超过了与其余代码的不一致之处。

没有书面标准也消除了繁文tape节，这可能会阻止公司团队为新项目尝试新的编码标准变体，或者是因为他们想尝试一些东西，或者可能是因为其他标准具有实际应用性他们使用的一些自动化工具上。

写下标准倾向于消除比原先预期更多的灵活性，同时也占用相当多的时间来做其他事情。我并不是说您永远不应该写下编码标准，书面标准肯定有其好处，特别是如果在不同位置工作的团队使用相同的代码库。

密切相关：编码标准的演变，您如何处理它们？

*如果人们在同行检查签入代码时不考虑，那么您的问题将不仅仅是编码标准。

改变它们成为主要障碍，人们将安全地遵守法律条文，而不是动脑筋去做正确的事。

会有一天，该标准的某些部分无济于事，并使代码更糟。有些人会遵守该标准，因为它已被记录下来并且是安全的，并且必须遵守规则。想要编写好的代码而不是符合标准的代码的人会感到沮丧和愤怒。会有争论和分歧，而如果不写下标准，就会有探索和讨论。

我认为这里的许多帖子都将编码标准与样式指南混淆了。

确保缩进多少空间是由不同团队开发的模块具有相同的编译器选项和ABI是另一回事。

像正确的方法来构建#include文件，而不是污染全局命名空间在头文件的东西应该被记录在案，使他们可以作为在初始编码和代码审查清单。

特别是“不要使用XXX，因为它会导致与YYY的兼容性问题”，您不会在后面的其他代码示例中看到它，因为它不存在。因此，让代码成为捕获标准的方式对于某些类型的标准可能不清楚或完全缺失，因此这不是一个通用计划。

诸如不使用异常或new在某些嵌入式系统中不使用之类的严重渗透和重要的事情不能简单地留给人们作为共同的文化知识，因为“信息是文化的（仅）”与制造标准（如ISO-9000）的基本原则相抵触，这些嵌入式系统的开发人员正在使用（例如，用于汽车应用）。这些重要的事情必须以正式的方式记录在案，签字并存档。

但这适用于编码，不适用于样式。

例如，C和C ++的发明者显示使用小写字母名称而不是 CaMelCaSe。那么，为什么有那么多开发人员不遵循源头上的隐含示例呢？标准库的风格和规范的教材难道不是随随便便的风格吗？

同时，人们确实遵循标准库标头的示例来处理不应复制的内容，例如使用__Ugly宏参数名称和包含文件非重复模式。

因此，有东西往往不被视为重要的风格，或者相反有例子可能不是很清楚，什么应该不遵循项目代码。两者都是对“样式”（或编码约定）最好保留为隐式的论点的反例。