Question

我参与了几个项目，我们花了很多时间讨论和编写精细的编码标准，涵盖从语法布局到实际最佳实践的所有内容。但是，我也发现这些很少被完全遵循。许多开发人员似乎毫不犹豫地拒绝仅基于编码标准违规的代码审查。即违规行为定期提交到存储库。

我的问题是：你有编码标准吗？它们涵盖了什么？他们是否跟着每个人？你做了什么（如果有的话）以确保每个人都遵守标准？

我知道有一个类似的问题here，但我关心的不是你如何做到这一点，而是你实际上是怎么做的以及有什么好处呢？

Answer 1

我曾在几乎没有遵循编码习惯的地方工作，而其他地方则接近执行 - 或者至少很容易检查。

一些建议：

最重要的是要获得一致性胜过个人喜欢的风格的想法。在编制标准制定之前和之后都应该对其进行讨论，但是不允许任何人选择退出编码标准。
代码审核应该是强制性的，签到评论包括审核者的用户名。如果您使用的是功能强大的SCM，请考虑不允许签名没有有效的审阅者名称。
应该有一个每个人知道如何制定编码标准的文件。有足够的细节，你不应该过多地讨论论点。
在可能的情况下，自动检查约定（通过Lint，CheckStyle，FXCop等），这样提交者和审阅者都可以轻松快速检查订购导入/使用指令，空白等内容。

好处是：

主要是一致性 - 如果您这样做，任何人都可以随时在代码库的任何部分感到“在家”，它会给您更多的灵活性。
传播最佳实践 - 如果你禁止公共领域，可变结构等，那么没有人可以在你的代码中意外地制造定时炸弹。（至少，不是标准所涵盖的定时炸弹。当然，没有完美代码的编码标准：）

编辑：我应该指出，在大公司工作时，编码标准可能最重要。我相信它们甚至可以帮助小型公司，但是那时对标准的处理可能更少。当所有开发人员彼此亲自了解并且所有开发人员都在同一地点时，它会有所帮助。

Answer 2

你有编码标准吗？

是的，项目与项目不同。

它涵盖了什么？

代码（类，变量，方法，常量），SQL命名和格式约定

每个人都跟着它吗？

是的，可以要求项目中的每个新进入者按照组织编码约定创建一个演示项目，然后进行审核。这项练习让开发人员在开始实际工作之前感到放心。

你做了什么（如果有的话）以确保每个人都遵守标准？

使用StyleCop和FxCop 确保他们被虔诚地遵循。如果代码无法遵守组织编码约定，它将显示为警告/错误。

Visual Studio Team系统具有良好的代码分析和签入策略，这会阻止开发人员检查不符合的代码

希望，这有帮助

谢谢，毛利克莫迪

Answer 3

我们使用Eclipse的保存操作和格式化程序。我们确实有一个建议的标准，但没有人实际执行它，因此实际格式化的内容和方式有一些变化。

这对我来说很麻烦，因为各种空白变体都被提交为SVN存储库的更新......

Answer 4

StyleCop可以很好地执行编码布局实践，如果基本规则中没有涉及对您很重要的内容，您可以为其编写自定义规则。

Answer 5

我认为编码标准非常重要。没有什么比试图找到文件的两个修订版本之间的差异更令人沮丧，只是发现整个文件已被重新格式化的人改变了。而且我知道有人会说这种做法应该被删除，但是大多数IDE都有一个'重新格式化文件'功能（例如，在Visual Studio中使用Ctrl-K Ctrl-D），这使得你的代码保持不变非常容易。

我看到项目由于缺乏编码标准而失败 - 我上一家公司的大括号战争导致团队崩溃。

我发现最好的编码标准不是团队中某人制定的标准。我在我们的团队中实施了由iDesign（click here）创建的标准，这可以帮助您避免在尝试实施自己的“标准”时可能产生的任何怨恨。

快速提及Code Style Enforcer（click here），这非常适合突出显示Visual Studio中的不合规。

Answer 6

我的个人和公司编码标准的组合在某种程度上仍在不断发展。它们涵盖了代码结构，测试以及描述各种功能的各种文档。

随着它的发展，我的团队其他成员正在采用和解释它。最终将会发生的部分原因是，如果某些部分存在共识，那么这些部分将会保持不变，而其他部分可能只是保留不一定符合要求的代码。

我认为可能会有一些尊重或专业钦佩作为一种让人们遵循编码标准的方式，其中某些部分在应用后变得清晰，例如：重构一个函数以使其更具可读性或将测试添加到某种形式，并使用各种“灯泡时刻”从Oprah中借用一个短语。

另一个好处是看其他人的工作情况，他们有什么样的技巧和技巧，以及如何随着时间的推移改善成为更好的开发人员。

Answer 7

我从未见过一个项目由于缺乏编码标准（或遵守它们）而失败，甚至对生产力没有任何影响。如果你花时间强制执行它们，那么你就是在浪费金钱。有许多重要的事情要担心（比如代码质量）。

为那些喜欢跟随某些内容的人创建一套建议的标准，但保留原则。

Answer 8

我认为，查看编码标准的最佳方式是根据您希望通过应用实现的目标，以及如果误用而可能造成的损害。例如，我认为以下内容非常好;

记录并提供单元测试，说明给定例程或模块使用给定接口的所有典型方案。
尽可能使用以下容器类库等...
使用asserts验证传入的参数和返回的结果（C＆amp; C ++）
最小化所有变量的范围
通过方法访问对象成员
使用new并删除malloc和free
使用规定的命名约定

我不认为强制执行这种风格是一个好主意，因为不同的程序员使用不同的风格是有效的。迫使程序员改变风格可能会适得其反，导致时间浪费和质量下降。标准应该简短易懂。

Answer 9

哦，是的，我是编码标准警察:)我刚写了一个简单的脚本来定期检查和修复代码（我的编码标准是simple enough来实现它。）我希望人们会收到消息在看到所有这些“编码惯例清理”消息之后：）

Answer 10

我们有一种“宽松”的标准。也许是因为我们无法就那些“在那里放置多少空间”，“在声明后或在下一行放置我的开放式支撑”的地方达成一致意见。

但是，由于我们有每个专用模块或组件的主要开发人员，以及可能在这些模块中工作的一些其他开发人员，因此我们有以下主要规则：

“坚持主要开发者使用的风格”

所以，如果他想做3个空格缩进，也可以自己动手。

这不太理想，因为它可能需要重新调整你的编辑器设置，但它保持了和平： - ）

Answer 11

你有编码标准吗？它涵盖了什么？

是的，它有命名约定，if之后的强制括号，while ...，不允许警告，建议32/64位对齐，没有幻数，标题保护，变量初始化和格式化规则，有利于遗留代码的一致性。

每个人都跟着它吗？你做了什么（如果有的话）以确保每个人都遵守标准？

大多数情况下，获得团队协议和稍微轻量级的编码标准（少于20条规则）对我们有所帮助。

如何执行？

轻轻地，我们没有编码标准警察。

在审核时检查标准的应用
我们有提供标准样板文件的模板文件

Answer 12

ParaSoft的JTest非常适合Java。

Answer 13

我们的编码标准列在我们的程序员手册中，因此每个人都可以轻松地参考它们。它们之所以有效，仅仅是因为我们从所有团队成员那里购买，因为人们不会害怕在代码审查期间提出标准和样式问题，并且因为它们允许一定程度的灵活性。如果一个程序员创建一个新文件，并且她更喜欢将括号放在与if语句相同的行上，那么它将设置该文件的标准。将来修改该文件的任何人都必须使用相同的样式来保持一致。

我承认，当我第一次阅读编码标准时，我不同意其中的一些。例如，我们对函数声明使用某种样式，如下所示：

    static       // Scope
    void         // Type declaration 
func(

char   al,                //IN: Description of al
intl6u hash_table_size,   //IN/OUT: Description of hash_table_size
int8u  s)                 //OUT: Description of s
{
<local declarations>

        <statements>
}

我之前从未见过这一点，所以起初对我来说似乎很奇怪和陌生。我的直觉反应是，“嗯，那是愚蠢的。”现在我已经在这里待了一段时间，我已经适应了风格并欣赏我如何快速理解功能声明，因为每个人都这样做。

你有编码标准吗？如果是这样，他们是如何执行的？

13 个答案: