我知道已经证明编码标准可以提供极大的帮助。但是，有许多不同的工具和IDE可以格式化为程序员喜欢的任何标准。只要代码整洁/评论（而不是意大利面条混乱），我就看不到需要编码标准。

是否有关于开发编码标准的争论（我们没有一个，但我一直在考虑创建一个）？

但是，有许多不同的工具和IDE可以格式化为程序员喜欢的任何标准。

祝你好运。以我的经验，只有极少数的工具（零！）可以正确地将代码从格式X格式化为格式Y。制表符与空格，多行语句等。只需看一下GNU对C ++标准库文件的实现。您可以做的就是让您的IDE始终使用空格而不是制表符，而不必费心重新格式化外部代码。现在，您的代码看起来像您喜欢的样子，而外部代码看起来像原始作者编写它的样子。

特定的缩进样式是编码标准应指定的最后一件事。那正在发动一场编程宗教战争。IMO，一种编码标准应指定一套合理的可接受的缩进样式，但具体细节留给软件包的作者。缩进样式是或应该是编码标准的一小部分。编码标准的零号规则：不要汗流the背。缩进样式是一件小事。

更大的东西：

• 我如何命名事物？
• 语言的某些部分是否超出限制？
• 代码是否需要进行干净的编译，以及使用哪些编译器设置？
• 代码是否必须通过某些指标？
• 需要什么样的测试？
• 在代码（注释）和其他地方都需要什么样的文档？
• 最重要的是，如何获得豁免标准？

附录
也许甚至更重要的是不包含在编码标准中的内容。诸如如何编写要求之类的主题不属于编码标准。关于测试的细节也不属于。项目不应使用编码标准作为项目管理计划，测试管理计划，验证计划的替代。编码标准的目标是提高代码安全性，质量，可理解性，可维护性，和其他“污秽”。有很多方法可以确保不会发生这种情况。仅举几例：使标准成为一本与某些国家的税法一样复杂的书，煽动编程战争，并制定不良的命名约定。

编码标准可能会产生意想不到的后果。例如：一个项目工程师的一些傻瓜会解释“无幻数治”意味着if (index == 0) {...}和for (ii = 0; ii < 3; ++ii) {...}必须更改为if (ZERO == index) {}与for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}不笑。我已经看到了它的发生。如今，当我编写编码标准时，这是“没有魔术数字的准则”，而不是消除这种愚蠢的规则。

编码标准并不是针对不良编程风格/危险编码实践的第一道防线。代码审查是。尽管进行了许多年的自动化，但没有什么比让主观的人眼观察并通过大量代码做出判断更好的了。

编码标准不仅涉及受支持的参数indent-它们还包括命名约定，注释约定，以及大量关于成语，使用语言功能的建议。

更重要的是，您仍然需要在所有地方记录所有这些信息。最后，并不是每个人都希望使用以这种方式重新格式化代码的IDE ...

如果您在团队中使用一致的样式，则代码将更易于阅读。当您的代码变得更易于阅读时，您的团队将变得更有效率。它们将变得更有效率，因为它们不必在脑海中解析代码，并且在查看和维护代码时可以专注于逻辑而不是语法。

如果每个人都让IDE重新格式化代码以选择他们，那么您将遇到以下两个问题之一：要么必须确保在保存时始终将其转换回原始格式，要么因为差异会显示很多噪音，使得很难看到代码逻辑中发生了什么变化。

简短的回答：是的，它确实反映了质量。

这是什么，为什么我们需要它？

编码标准是高质量软件中非常重要的一部分。它们确实提高了开发过程的生产率，使代码更易于维护，并且避免将代码绑定到一个人或团队中。编码标准的一致性还将过早创建的代码与精心制作的艺术品区分开。

好的，每个开发人员都知道编码约定是好的。但是标准应该从哪里来？

它主要由拥有产品的供应商决定。每个开发人员都可以从许多行业编码标准中进行选择。Microsoft，Oracle和Sun Microsystems的某些公司提供准则。

是否有关于开发编码标准的争论（我们没有一个，但我一直在考虑创建一个）？

是的，建议使用行业标准。但是，每种编码标准都是特定于开发平台的。因此，编码标准主要是特定于语言的。例如，Java与.NET具有不同的标准。例如，C＃.NET在本参考中使用该标准。

通用标准

通用标准不依赖任何编程语言。除了供应商提供的标准（又称上述行业编码标准）之外，还有其他编程符号，例如匈牙利符号或CamelCase。我认为Microsoft .NET编码标准最初是基于CamelCase表示法的。

团队编码标准和准则

在思想上，每个开发团队都应该在项目开始时就编码标准达成一致。编码准则通常由团队负责人或公司的首席架构师创建。它通常是一个公开文档，需要时应加以遵循和改进。例如，在我们的公司中，我们有Wiki页面，此文档已上传到该页面，可供公司开发人员使用。

我将接受有争议的意见，并说不，您不需要编码标准。就像您所说的那样，这些规则是IDE强制性准则，每个公司的每个人都应遵循的一般最佳实践，或者是每个团队的逐案判断调用，应由一个有能力的团队中的多个人员做出通过配对编程或代码审查。

我们应该如何命名该变量？我们应该使用哪些语言功能？我们应该避免吗？什么测试是最好的？最好不要回答这些问题，直到遇到当前我们正在解决的狭义问题。

从这些微小的决定中结晶出来，基于与当前问题域和所使用技术的交叉点，团队中可能会出现非正式的标准/模式。整理这些意味着我们认为，基于数百个微决策并被这些团队非正式采用的，用于这些项目的诸如命名标准，适当的语言子集之类的东西，应该指导每个项目的前进。

从原则上讲，这听起来像是一件伟大的事情，但实际上，它只是成为政治的磁铁。我们可以强迫所有人使用哪些工具？我想强迫别人避免什么？如果每个人都同意这些问题，我们将不需要一个标准。我们会做的。以我的经验，标准源自对一个开发者子集对另一子集行使控制的愿望。通常，这种政治形式和随之而来的技术政策只会扼杀创新，而不是提供指导。

如果您想要真正的指导，而不是阅读带有无用规则的标准，请去寻找团队中有能力的成员，并询问他们的想法。他们被什么烧死了？他们如何建议您编写代码？您将获得各种有用的答案以及许多宝贵的经验来进行备份。根据常见的经验，您会看到很多交叉路口。除了标准强制实施的单一文化之外，您还将看到很多多样性，这些多样性只能帮助您看到解决问题的许多有效方法。

当有人告诉您不要执行“标准”规则中的某项规定，但是对他们的主张没有经验或没有合理的支持时，请忽略它们。这里的标准并没有为任何人服务或使任何人成为更好的开发人员。

现在，商用飞机是电传操纵，您希望基于飞行员的输入工作的飞机操纵程序。程序员编写此类代码时，希望他们遵循一套严格的规则，以避免通常可以避免的编程错误。一种实现方法是使用编码标准。

请参阅：联邦航空局C和C ++编码标准提案

需要我多说。

注意：我无法从FAA在线找到实际的标准，但是我已经看到了。

对我而言，纪律和纪律总是有帮助的，这反映了您制作的作品的质量。

话虽如此，我将使编码标准与IDE和/或使用中的工具保持一致。此外，对于每个开发人员，IDE的配置应相同（例如，每个开发人员的IDE应该使用所有制表符或所有空格进行缩进，并且每个人的IDE应该具有相同的制表符长度），以便每个人都可以轻松遵循标准...

同样，可以开发和使用签入脚本，这可以在一定程度上帮助遵守编码标准，例如，它们可以在实际将签入文件提交到版本控制系统之前修复缩进。

编码标准再重要不过了！我是CakePHP的狂热用户，我想查看从版本到版本的变更集，而开发人员并未遵循那里的标准。

实际上，我对风格上的差异感到非常沮丧，以至于我不得不写一篇关于编码约定的短篇小说。将新开发人员带入现有团队需要花费大量的时间和金钱-想象一下，没有标准的新开发人员接...而至...学习代码将是非常不可能的。