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

#1 楼

原因有很多。


没有人阅读文档。
即使他们读过文档也没有人遵循。
编写一系列实践要比建立一种文化有效得多。当人们偏离标准时，应该通过代码审查过程和/或自动工具来加以纠正。

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

#2 楼

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

不要在文档中捕获编码标准。通过具有验证标准是否符合要求的自动化过程，将其捕获在代码中。已经存在的代码，并标识什么约定和巧合。

将Checkstyle之类的内容合并到提交构建中。这可以强制执行诸如格式和命名标准之类的基本规则，而不是花时间在考虑样式上，而可以将所有这些工作转移到一个愚蠢的过程中，这至少可以保证是彻底的。至关重要，然后严格定义您想要的是什么，如果错误则失败。

#3 楼

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

编码标准中的大多数决定只会对可读性和生产率产生很小的影响。特别是如果您对语言采用“常规”风格，并且语言设计师开始意识到这应该是规范的一部分（例如Go）。会变得非常热烈，并且持续不断，对生产力和团队凝聚力造成了真正的损害。或者可以通过在两个或更多个人的首选样式之间进行无休止的重新格式化来掩盖您的变更历史。管理者可以指出这一点，并转移对文档的不满。您可以用一张纸争论，但不会听您说。

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

#4 楼

因为注释是谎言。

编码标准对应该的代码有很大的影响。代码本身就是真理的最终来源。在这种情况下，真相不是代码行为，而是它所表达的样式。如果您的标准尚未反映在代码中，那么您还有很多工作要做。注释是程序员的个人失败，因为它证明他没有设法用编程语言本身表达代码片段的目的。同样，标准文档也无法在代码库中表达连贯的风格。不得不叹息。）

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

拥有代码标准很重要。拥有说明它们不是什么的文档。

#5 楼

为什么鲍勃叔叔建议如果可以避免的话，不应该写下编码标准？仅当他将在此处发布答案时才回答（我们的意见无关紧要），但是...


为什么我不应该写下编码标准？ />
如果您要问他是否正确：让我成为（到目前为止）唯一不受欢迎的人，说您没有理由避免这样做。

写信下。但是，我将尝试解释我的原因...

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

Bob叔叔的措辞并不能使我认为他是在谈论那件事。

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


在某些情况下，法律要求书面编码标准。
我确实阅读过文档，但我肯定并不孤单。团队成员可能会随着时间而变化，知识不会存在于5-10年的代码库中或团队成员的头脑中。组织应解雇不遵守内部准则的人员。
编码标准一旦获得批准，就不会经常更改，如果您愿意知道，也可以更改。如果标准发生更改，则您的文档（以代码形式）已过时，因为您的所有代码均未遵循新标准。重新格式化/重构可能会很慢，但是您始终要遵循书面权威指南。
阅读5页文档比检查10 / 20K LOC推断规则要好（BTW您可能会误解），毫无疑问。
具有讽刺意味的是，曾经写过许多有关设计原理和编码风格的书的人建议您不要编写自己的指南，那么如果他给我们扔一些代码示例会更好吗？不，因为书面指南不仅会告诉您该怎么做，而且还会告诉您代码缺少的其他两件事：不做什么和不这样做的原因。对16岁的忍者来说不错，但是组织还有其他要求：必须在公司级别授予（定义）代码质量-这不是一个团队可以决定的事情。他们甚至可能没有能力决定更好的方法（例如，有多少开发人员具备审查MISRA或什至仅了解每条规则的全部技能？）
成员可能会跨不同团队迁移：如果每个人都遵循相同的编码标准，则集成是平滑的，并且不易出错。
如果团队是自组织的，则随着团队成员的变化，这些标准将随着时间的推移而发展-您将拥有一个庞大的代码库，该代码库不会遵循当前公认的标准标准。

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

当然，只有一个团队的小型组织可以让团队决定采用的标准，但是必须将其写下来。您可以在Programmers.SE上阅读Eric Lippert的帖子：我想我们都同意他是一位经验丰富的开发人员，当他在Microsoft工作时，他必须遵守他们的书面准则（即使某些规则可能是错误的，不适用的或无用的）对他。）乔恩·斯基特（Jon Skeet）呢？ Google准则非常严格（许多人不同意），但他必须遵守这些准则。对他们不尊重吗？不，他们可能致力于定义和改进此类准则，公司不是由一个成员（或一个团队）组成，每个团队也不是一个孤岛。 >
您决定不使用C ++中的多个继承和嵌套类，因为您的实际团队成员对此不太了解。后来，想要使用多重继承的人必须浏览整个1M LOC，以查看它是否曾经被使用过。这很糟糕，因为如果没有记录设计决策，则您必须学习整个代码库才能理解它们。甚至在那时，如果还没有使用它，那是因为它违反了编码标准，还是被允许使用，但是在以前的情况下，多重继承才是合适的选择？具有重载的方法来提供默认参数，因为当C＃中没有可选参数时，您的代码库已启动。然后，您进行了更改并开始使用它们（重构旧代码以在每次必须修改此类功能时使用它们）。甚至以后，您仍然认为可选参数不好，因此开始避免使用它们。您的代码告诉您什么规则？这很不好，因为标准在发展，但是代码库在发展却很慢，如果是您的文档，那么您就麻烦了。
乔恩（Jon）从A队搬到了B队。在学习过程中，他可能会引入更多的细微错误（或者，如果幸运的话，只需花很长时间来理解现有代码并延长代码审阅时间）。完全不同的编码标准。改写？适应？混合？所有这些都同样糟糕。


Bob叔叔


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


没错，直到您没有标准为止，并且您的组织已为您分配了建立标准的任务。特定于公司。


不，出于上述所有原因。即使您只是想将代码格式化形式化（您可能想对形式化进行的最无用的事情），我仍然怀念着无休止的（无用的）关于格式化的战争。我不想一次又一次地活下去，将它们全部设置一次。


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


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


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


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


确保每个人都知道标准是关于沟通的，而没有别的。


不仅要有一个好的标准，除非您只想对次要细节有一个标准。


经过前几次迭代，让团队共同决定。


首先要了解的是，别忘了编码标准通常是一个需要花费很多年才能开发和完善的过程：迭代很少，也许是初级开发人员？真？您是否要依靠一位资深（如果有）成员的记忆？ ，例如在C ++中，甚至比Java中更需要公司级标准。
如果您在一家只有一个小团队的非常小的公司中工作，则这种推理可能并不完全适用（鲍勃叔叔的原因可能不太极端）。
您被录用（作为团队）并且您将单独处理一个新项目，然后您将忘记它并继续前进。在这种情况下，您可能不在乎（但您的雇主应该...）

#6 楼

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

#7 楼

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


有很多原因。以下是一些注意事项：


人们花多少时间花“学习”代码标准只是为了让大量时间投入到整个团队的审查，讨论，文档编制，修订等工作中。代码标准这就像在不断讨论您的“员工手册”-将它多长时间列在团队会议的议程上？？？？？那么留下来的少数人通常无法继续遵守（甚至可能没有阅读过）标准。接下来您会知道，所有用于“保持代码干净”的工作都被浪费了。想要以一种新的方式来做。同样，通过编纂标准可以获得什么？？

您应该确保阅读＃6：确定。


换句话说，当需要启动一个项目时，只需花一会儿时间即可。然后讨论当前团队正在使用的编码标准的一般规则-并基本遵循它们。这样，您就可以最大程度地提高改进产品的工作量，同时又可以减少编写，查看和记录获取可执行代码所需的“语法糖”所需的工作量。来自编码标准。通常，“可读性”过于含糊-大多数开发人员不会从间距，换行等确切的规则中受益匪浅，但是您可以通过至少设置一些规则来避免不断惹恼开发人员。

#8 楼

我认为还没有足够清楚地阐明另一个答案，那就是这也意味着人们不会盲目遵循规则。这意味着人们必须为他们的设计决策和编码约定提供实际的理由，而不仅仅是依赖于已被写下来证明其事实的事实。

#9 楼

首先，据我所知，鲍勃叔叔是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 ++编写应用程序的开发人员组成的团队的世界里。发展多年。由于HTML / CSS / JScript等的设计存在缺陷，我希望Web UI开发人员仍然需要编码标准。

#10 楼

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

#11 楼

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

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

#12 楼

尚未明确说明的一个非常重要的事情是，编码标准就像语言一样：它们在不断发展。书面的编码标准阻碍了这一工作，如果不是这样的话，它就会不断地过时并且毫无用处。如果您在签到时进行同行评审，则每当有不符合编码标准的内容进入存储库时，这意味着有2个人考虑了此事*，并决定此变更的好处超过了与其余代码的不一致之处。 br />
没有书面标准也消除了繁文tape节，这会阻止公司团队为新项目尝试新的编码标准变体，因为他们想尝试一些东西，或者因为不同的标准在它们使用的某些自动化工具上有实际的应用。可以花在做其他事情上。我并不是说您永远不应该写下编码标准，书面标准肯定有其好处，尤其是如果在不同位置工作的团队使用相同的代码库。

密切相关：编码的发展标准，您将如何处理它们？ >

#13 楼

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

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

#14 楼

我认为这里的许多帖子都将编码标准与样式指南相混淆。 br />
应该记录诸如构造#include文件的正确方法并且不污染头文件中的全局名称空间之类的内容，以便在初始编码和代码审查期间将它们用作清单。 br />特别是“不要使用XXX，因为它会导致与YYY的兼容性问题”，在后面的其他代码中，您不会看到示例，因为它不存在。因此，让代码成为捕获标准的方式对于某些类型的标准可能不清楚或完全缺失，因此这不是一个通用计划。在某些嵌入式系统中不使用new不能简单地留为共同的文化知识，因为“信息是文化性的（仅）”与制造标准（如ISO-9000）的基本原理相矛盾，这些标准是这些嵌入式系统的开发人员正在使用的（例如用于汽车应用）。这些重要的事情必须以正式的方式记录在案，签字并存档。例如，C ++显示使用小写名称而不使用CaMelCaSe。那么，为什么有那么多开发人员不遵循源头上的隐含示例呢？标准库的样式和规范教材不是应该遵循的不当样式吗？

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

因此，拥有东西通常不被视为重要的风格，或者相反，对于项目代码中不应遵循的内容，拥有示例可能并不明确。两者都是对“样式”（或编码约定）最好保留为隐式这一论点的反例。