代码格式准则有多重要？[关闭]

编码标准在任何软件开发组织中都很常见，但是遵循这些标准有多重要？我可以理解需要一些一致性，但是当处理简单的事情（例如花括号的位置，行长等）时，我不确定过于严格的标准会对软件开发做出很大的贡献。

您的代码可读性不是更重要，不符合预先定义的标准吗？无论如何，它们似乎更像是……准则。

要求每个人100％遵守相同的标准代码格式指南，就像要求每个人在编写100页具有相同写作风格的论文时进行单独协作。

希望每个人都可以用英语（或相同语言）写论文，但是风格会很明显。有些人会写得很好，其他人则不会。有些人会使用收缩，有些人会完全拼出单词（例如：这是事实）。等等。

我认为您提到了最重要的几点：

1. 这是一个准则
2. 可读性

如果您希望代码遵循相同的格式，例如纸张具有相同的书写风格，则需要进行编辑和修改。该代码将需要清理，审查，重构等。

我从来没有去过一家商店，在那里我对另一个开发人员的编码风格或格式感到完全满意（至少因为它与我的不完全一样）。但是，如果我能阅读/理解它并且保持一致，我会感到满足。 其他所有内容都是语法糖上的糖。

因此，回答您的问题：有点重要，但是如果他们不这样做，那肯定不是世界末日。

对于格式标准，我遵循其他人正在做的事情。如果他们使用PascalCase进行所有操作，那么我将使用PascalCase。如果他们使用_camelCase，那么我使用_camelCase。为什么？因为它限制了我重新格式化的数量，并限制了其他人必须做的事情才能使其看起来“不错”。通常存在格式化标准，以使每个人都很容易。

在我目前的工作中，我的首要任务之一是为我们的开发小组提出一个编码标准。

我的第一篇论文大约60页长（它包含了Microsoft的许多Framework Guidelines）。我被要求将其削减，然后我的下一个工作是十页长，利用了来自各种良好来源的想法。我认为我被要求再次缩减，最后缩减至三到四页。

它从未被采用。

为什么？因为我与很多非常聪明的人一起工作，所以他们已经本能地遵循明智的编码标准。

就我而言，我遵循Microsoft普遍接受的指南，并模仿其他人的常用样式（Javascript和jQuery的格式与 C＃不同，即使它们都是花括号语言）。我也会不时地打破规则，这样做会使代码更具可读性。

如果您使用的IDE可以为您做这件事的基础（例如Visual Studio），那么让IDE来做就可以了，只要您仍然让IDE来做，那么看起来很难修改的东西就可以了，或者下一个自动格式化它的人还是会杀死它。

一个人最容易理解的内容并不适合所有人。

如果您不使用这种IDE，请选择一个。甚至超过10分钟的思考时间，IMHO都会浪费资源。

我认为帮助快速理解代码有一个未提及的好处。在项目和所有开发人员中，代码格式设置越相似，您就越容易（并且在下意识上）使用代码。

在尝试长时间解决甚至简单的错误之后，我就有初级开发人员来找我。在花了几分钟与他们一起应用我们的代码格式之后，他们很快就能看到以前错过的错误。

虽然可读性绝对重要。如果您的代码格式标准经过深思熟虑并得到正确使用，您可能会发现不仅可以阅读代码，而且可以更快地理解代码。

我在开发或更新编码格式时使用的一组准则是格式塔分组原则-http: //en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping

作为直接的结果/示例，我们的代码格式要求任何块代码（如果有，开关等）在下一行都具有开括号，以便使其与闭括号对齐：

if(true)
{
}

通过对称原理的推理，您的大脑将看到打开和关闭的花括号，并且可以更快地自然地感知代码块。

无论您使用哪种语言或工具，都可以想到一些东西。配置您的IDE并签入配置文件。

当任何人签出项目时，他们将使用相同的格式样式。样式是什么都没有关系，只是样式是一致的。对于空格和制表符，我有自己的偏好，大括号在哪行上继续。但是，除了我个人的喜好外，我还只是在乎给定的源代码文件是否与自己相符。它比格式战争产生的杂乱无章的可读性高得多。

到目前为止，我遇到的最糟糕的事情是没有使用任何编码标准。并且禁止您使某些代码块更具可读性，因为它破坏了diff工具...因为我们使用补丁来应用更改（更改/错误修复请求->修复/更改->补丁->“受信任”人员应用的补丁-> commit）（从可读性的角度来看），您可以获得非常有趣的源代码。至少我们没有任何人使用两个字母变量（-。

[rant]最有趣的是，每个人都同意我们需要改变这一点。甚至进行了两次重新格式化的尝试（在提交时自动进行），但是由于缺少一个小的“小小的”格式化选项-所有事情都解决了。视线... [/ rant]

准则有助于提高代码质量：

• 从作者的角度来看：许多规则旨在减少错误的引入。例如，规定if()或for(;;)构造必须紧跟着一个块而不是单个指令的规则，可以使初始编码者的意图变得明确，并帮助下一个编码者维护这一点。

• 从读者的角度来看：遵循约定准则的代码比具有各种样式的代码更有效地进行审查。审阅者会更轻松地了解如何查找可能的错误。

对于团队应该做什么或不应该做什么没有统一的标准。有些团队需要遵循严格的准则，有些则不需要。

关键是，您应该作为一个团队一起工作，并确定最适合您的团队的东西。代码应该易于阅读，因为它被读取的次数比被写入的次数高。如果您的团队需要有关创建可读代码的指导，请遵循编码标准。如果您不这样做，请不要。

话虽这么说，我认为大多数团队都将从同意使用标准方法来命名变量，函数和类，位置括号等中受益。如果团队不能就这么简单的事情达成共识，那么他们又怎能期望他们在一起做出真正重要的决定？另外，您的团队将永远不会由同一个人组成-人们离开，新员工被雇用。新人越容易破解代码库，他们就可以更快地为团队做出贡献而又不降低代码质量。