编码标准应该是什么？ [关闭

Question

在良好（阅读：有用的）编码标准中应该是什么？

• 代码应该拥有的东西。
• 代码不应该有的事情。
• 编码标准是否应该包括语言，编译器或代码格式化器执行的内容的定义？
• 诸如循环复杂性，每个文件等线等的指标呢？

Answer 1

每个要求的原因。这样，遵循标准就不会成为某种货物邪教，人们知道，如果不再适用的原因，可以更改标准，或者在特定情况下违反标准，因为原因显然不适用。

Answer 2

标签与空格！当我的一位同事意外地将很多标签转移到空间中时，我会得到疯狂的更新

Answer 3

命名约定

编辑： 我的意思是命名指南，而不是命名规则。

例如，指南将是 All boolean values should begin with Is/Can/Has/etc when possible. 。规则将是 All boolean values must start with Is

Answer 4

组的编码标准应包括 警告和错误的编译器选项 必须解决。

程序员应该可以自由 增加 警告自己的代码，但必须有一个基线，以便阅读和使用他人的代码不会使您从编译器获得的输出混乱。

这样的标准还必须解决程序员如何禁用此类警告，如果有一条杰出的代码不符合，则该警告。

Answer 5

我喜欢的一些标准（我知道有很多标准，但这就是我喜欢的）：

• 80％的单位测试覆盖范围
• 代码的集体所有权（写代码要由您的团队伴侣阅读，而不是编译器）
• 写评论。写你对新来者说的话。
• 把事情简单化

Answer 6

Coding Standards help a little when you are writing the code the first time, they help a lot when you, or your replacement, has to update the code 2 years later.

The ideal standard leads to code where you can jump to any arbitrary page in the code, and understand excactly what it is doing on the first read-through, because

• the names clearly describe what data is being manipulated,
• the braces make the flow of control clear,
• the comments explain any non-obvious algorithm, etc.

On the other hand, too many arbitrary standards can disrupt the flow of writing code. So I believe that every item in a proposed coding convention should be evaluated against these 2 criteria:

• Does this rule help ensure that the code is Correct?
• Does this rule help ensure that the code is Clear?

If neither is true, the item is just arbitrary, and probably unnecessary

---

I would include the following things in a standard I write:

For Clarity:

• File Organization: Specifying a fixed order for the items in a file lets the team easily navigate others files. You shouldn't have to hunt to find #defines, or structure definitions.

• Naming conventions: Consistent naming aids readability. But avoid over-specifying too many rules, that harms writeability.

• Code Structure. Curly Brace placement, indentation levels, spaces vs tabs, etc. Yes, this can be a strong personal preference, but the goal is clear code. Find the best option for the team, and stick with it.

For Correctness:

• Best Practices specific to your problem type: Rules about memory allocation, or concurrency, or portability.

• "Const Correctnesss", proper use of static and volatile, etc.

• Rules about preprocessor macros, and other easily abused features of the language.

Answer 7

鼓舞人心的务实思想，使人们思考，而不是阻止人们思考的负面限制。

否则，您会得到代码猴子，他们害怕追随 香蕉.

Answer 8

编码标准应该是什么？尽可能少。少更多。请有理由。

不是因为我是一些不想要流程的牛仔编码器，而是因为我看到了较重的编码规格，而没有逻辑后面的逻辑（大概是）“我在'95年的'nopher of''网络上都发现了这一点，最终才变成官僚主义的噩梦。

老实说，有些人似乎相信，通过制定标准，他们将看到代码“质量”的相应增加，也许通过这种衡量标准。同时，他们将忽略体系结构，性能，常识和其他最终比文件中的行数重要的事物。

Answer 9

代码审查的程序来执行该标准。哦，也要找到错误。

Answer 10

一些古老的常识不会不对劲。有太多的编码标准文档，这些文档在无关紧要的位置（例如字体类型和大小等项目之一）。

如果您在一组开发人员中，最好的办法是互相交谈并查看您的代码，就可以接受的内容构成共识，如果您需要将主要要点写入指导方针，但请将其保留为只是指南。如果您不能证明与准则的任何分歧合理，那么您确实应该考虑为什么要这样做。

归根结底，清晰可理解的代码比任何关于布局或版式的严格规则都更为重要。

Answer 11

正如其他人提到的那样，代码测试覆盖范围很重要。我也喜欢看：

• 项目结构。测试是代码的一部分，还是在单独的项目/软件包/目录中？ UI代码是否与后端内容一起使用？如果没有，它如何分隔？

• 发展过程。在代码之前写测试？固定破碎的构建是否优先考虑开发？什么时候进行代码审查，应该涵盖什么？

• 源代码管理。什么时候可以检查什么？设计文档和测试计划是否受到控制？您什么时候分支，什么时候标记？您是否保留以前的构建，如果是的，有多少/有多少时间？

• 部署标准。构建如何包装？发行笔记需要什么？如何创建/控制/运行升级脚本？

忘记所有关于命名约定，格式以及在函数/方法/模块中可以使用多少行的废话。一个规则：在您要编辑的任何内容中使用现有样式的任何内容。如果您不喜欢某人的风格，请在代码审查中将其分开。唯一的例外可能是TABS-VS空间的内容，仅仅是因为许多编辑/IDE会盲目地将一个转换为另一个，然后您最终摧毁了变更历史记录，因为每行都会更改。

Answer 12

我认为实际上有两件事要解决，实际上我会分别考虑它们，因为它们不能以相同的方式与他们接触，尽管我觉得这两者都很重要。

• 技术方面：旨在避免有风险或形成不良的代码（即使被编译器/口译员接受）
• 演示方面：这与使读者清晰的计划有关

我资格的技术方面 编码标准, ，就像一样 草药萨特 和 Andrei Alexandrescu 和他们的 C ++编码标准. 。我有资格的演讲 编码样式, ，其中包括命名约定，缩进等...

编码标准

因为它纯粹是技术性的，所以编码标准可能是客观的。因此，每个规则都应由一个原因支持。在我提到的书中，每个项目都有：

• 标题，简单而要点
• 摘要，解释标题
• 讨论说明了这样做的问题，因此说明了 理由
• 可选的 一些例子，因为一个很好的例子值得一千个字
• 可选的 无法应用此规则的例外列表，有时在围绕
• 讨论了这一点的参考文献列表（其他书籍，网站）

基本原理和例外非常重要，因为它们总结了原因和何时。

标题应足够明确，以至于在评论期间只需要使用标题列表（备忘单）即可。显然，按类别对项目进行分组，以使人们更容易寻找一个项目。

Sutter和Alexandrescu设法仅包含一百个项目的列表，即使C ++被认为是毛茸茸的；）

编码样式

这部分通常是不太客观的（并且可以是彻头彻尾的主观）。这里的目的是保证一致性，因为这有助于维护者和新来者。

您不想在这里输入关于哪种凹痕或支撑风格更好的圣战，有一些论坛：因此，在此类别中，您可以通过共识>多数投票>领导者的任意决定来做事。

有关格式的示例，请参阅 艺术风格. 。理想情况下，规则应清楚而完整，以使程序可以重写代码（尽管您不太可能会编码一个；））））

对于命名约定，我将尝试使类/类型轻松地与变量/属性区分开。

我在此类别中也将“度量”类似：

• 喜欢短而长的方法：通常很难就长时间达成共识
• 喜欢提早返回/继续/休息以减少凹痕

杂项？

作为最后一句话，有一个项目很少在编码标准中讨论，也许是因为每个应用程序是特殊的：代码组织。建筑问题也许是最杰出的问题，即最初的设计陷入困境，从现在开始，您会困扰着它。您应该添加一个用于基本文件处理的部分：公共/私人标头，依赖关系管理，关注点分离，与其他系统或库进行接口...

---

但是那是 没有什么 如果它们实际上没有应用，并且 执行.

在代码审查期间，应提出任何违规行为，如果违规行为未偿还，则不应可以审查：

• 修复代码以匹配规则
• 修复规则，以使代码不再突出

显然，改变规则意味着从领导者那里获得“继续”。

Answer 13

我喜欢格式 框架设计指南 它包括准则的一般部分和理性。最有用的位是从做，不，避免和考虑的细节。

这是本节中的一个示例 明确实施接口成员 它具有以下项目（请注意，出于残骸的缘故，我放弃了理由）

避免 明确实施接口成员而没有有力的理由

考虑 如果仅通过接口调用成员，则明确实现接口成员。

不要 使用显式成员作为安全边界。

做 提供一个受保护的虚拟成员，如果要通过派生类专业的功能，则提供与>显式实现的成员相同的功能。

这会产生良好的总体语气。通过避免和考虑，您可以允许开发人员使用他们的判断力。同样，因为它们是准则，而不是规则开发人员可能会发现他们更可口，进而更有可能遵循它们。

Answer 14

似乎没有人提到过安全性 - 在编码标准中，您必须参考安全代码要求（例如，使用输入验证模块，不称呼已知的弱功能，例如strcpy，错误处理要求等）

Answer 15

例子。 整齐地安排，非平凡的近乎实现的示例，可以利用每个规则。注释（不一定是代码的一部分）示例的哪一部分遵循哪个规则。

模板。 不是C ++的种类，而是复制的东西，并充满活力。当您有参考文献复制时，正确获取24线样板评论要容易得多。

Answer 16

第一名：绝对最多两页。

这是您希望每个开发人员阅读和记住的东西。每当您需要编写新功能（或更糟的是新行）时，您不必在标准中查找。因此，保持简短，仅保留真正为最终产品提供更多价值的规则。

Answer 17

编码标准实际上是几个项目：

编码约定

• 这些事情不需要其他原因，而是“代码基础的一致性”。是否在私人成员变量中使用“ _”。
• 可能有几种正确的方法。只需要选择一个以保持一致性即可。对于前。使用异常或错误代码处理错误。

最佳实践

• 这些项目总是需要一个充分的理由，有一些明确的例子

对于前。尝试后切勿空无一人

try { Foo(); } catch { //do nothing }

1）如果FOO（）抛出了一个例外，则可能会在以下功能上引起其他问题，认为FOO是成功的。

2）全局错误处理程序在prod上发生时不会通知支持团队的异常

• 涵盖“防御性编码”的做法，例如使用断言来测试您的假设。

编码环境

• 整个团队使用的工具。对于前。 VS 2010，Resharper，Kiln等。

Answer 18

编码标准在纸上写时，仅有效。我喜欢Go如何发布其编码标准。它有工具 gofmt 将程序文本格式化为格式。然后，关于编码格式的任何辩论将仅作为补丁作为补丁 gofmt.

至于格式应有的

• 如何命名变量，宏，常数，文字，功能等
• 如何放置{，}，（，），[， if, ，功能主体，用于任何其他目的的语句块，
• 压痕应有多宽，
• 允许有多少个字符
• 在拒绝/发送代码进行重构之前，允许多少级别的凹痕
• 每个功能都允许使用多少行代码进行重构
• 函数可以在将其发送回来之前可以采取的最大参数数量
• 如果身体要超过屏幕代码的一页，则在函数开始之前开始简要解释它的作用；离开函数体内代码的对象如何实现对象

当我阅读他人（主要是C语言）代码时，如果变量/函数名称在项目的上下文中不直观，或者超过五个级别的缩进或函数，则需要超过六个或七个参数或函数运行。屏幕上的两三页，很难阅读和理解代码。当被要求进行增强/维护工作时，它只会增加困难。这让我希望 gofmt 像程序一样，为每个项目（甚至语言）编写，并且每个源代码文件都可以通过该程序运行，然后才能将其投入项目。

Answer 19

我喜欢 Google JavaScript样式指南.

如果您需要，它的指南中就是简洁的，但有细节。

Answer 20

自我记录的代码（评论，变量名称，函数名称等）