Do you have coding standards? If so, how are they enforced?
我曾在几个项目中工作过，在这些项目中，我们花费了大量时间讨论和编写详细的编码标准，涵盖从语法布局到实际最佳实践的所有方面。然而，我也发现，很少完全遵循这些原则。许多开发人员似乎不愿仅仅根据编码标准的违反来拒绝代码审查。即，违规行为定期提交给存储库。
我的问题是：你有编码标准吗？它们包括什么？每个人都跟着他们吗？你要做什么(如果有的话)来确保每个人都遵守标准？
我知道这里也有一个类似的问题，但我关心的不是你能怎么做，而是你到底是怎么做的，你感觉到的好处是什么？
我曾在一些几乎没有遵循编码实践的地方工作过，还有一些地方他们很容易被强制执行——或者至少很容易被检查过。
一些建议：
- 最重要的是接受这样一个观点：一致性胜过你个人喜欢的风格。在制定编码标准之前和之后都应该讨论它，但是不应该允许任何人选择退出它。
- 代码审查应该是强制的，签入注释包括审查者的用户名。如果您使用的是功能适当的SCM，请考虑不允许签入没有有效审阅者名称的签入。
- 应该有一个大家都知道的关于制定编码标准的文档。有了足够的细节，你不应该在争论中得到太多。
- 在可能的情况下，自动检查约定(通过lint、checkstyle、fxcop等)，这样提交者和审阅者都可以很容易地快速检查命令导入/使用指令、空白等内容。
好处是：
- 主要是一致性——如果您使任何人在任何时候都能感觉到代码库的任何部分"在家"，那么它会给您更多的灵活性。
- 传播最佳实践-如果禁止公共字段、可变结构等，那么没有人会在代码中意外地植入定时炸弹。(至少，不是标准规定的定时炸弹。当然，没有完美代码的编码标准。)
编辑：我应该指出，在大公司工作时，编码标准可能是最重要的。我相信，即使是在小公司中，它们也能起到帮助作用，但在这一点上，围绕标准的过程可能就不那么需要了。当所有开发人员都认识彼此并且都在同一地点时，这会有所帮助。
你有编码标准吗？
Yes, differs from project to project.
< /块引用>
它包括什么？
Code(class, variable, method, constant), SQL naming and formatting convention
< /块引用>
每个人都跟着它吗？
Yes, every new entrant in project could be asked to create a demo project following organization coding convention then it gets reviewed. This exercise makes developer feel at ease before starting real job.
< /块引用>
你要做什么(如果有的话)来确保每个人都遵守标准？
Use StyleCop and FxCop to ensure they are religiously followed. It would show up as warning/error if code fails to comply with organization coding convention.
Visual Studio Team system has nice code anlysis and check-In policies which would prevent developers checking in code that does not comply
< /块引用>
希望，它有帮助
谢谢，莫里克莫迪
Stylecop在执行编码布局实践方面做得很好，如果基础规则中没有涉及对您很重要的内容，您可以为它编写自定义规则。
我们使用Eclipse的保存操作和格式化程序。我们确实有一个建议的标准，但是没有人真正执行它，所以在实际格式化的内容和方式上有一些变化。
这对我来说有点麻烦，因为各种空白变化都是作为SVN存储库的更新提交的…
我结合了个人和公司的编码标准，这些标准在某种程度上仍在不断发展。它们包括代码结构、测试和描述各种功能位的各种文档。
随着它的发展，它正被我团队的其他成员采用和解释。最终将要发生的部分事情是，如果某些部分存在共识，那么这些共识将保持不变，而其他部分可能只是保留不一定符合要求的代码。
我认为可能有一些尊重或专业的赞赏，这是一种让人们遵循编码标准的方式，其中的某些部分在应用后变得清晰，例如，重构一个函数以使其更可读，或在某种形式上添加测试，用不同的"灯泡时刻"借用奥普拉的一个短语。
另一个好处是看看其他人工作得有多好，他们有什么样的技巧和技术，以及如何随着时间的推移而改进成为一个更好的开发人员。
我认为编码标准非常重要。没有什么比试图找出一个文件的两个修订版之间的差异更令人沮丧的了，结果发现整个文件都被重新格式化的人更改了。我知道有人会说这种做法应该被淘汰，但是大多数IDE都有一个"重新格式化文件"功能(例如，在Visual Studio中使用ctrl-k ctrl-d)，这使得代码的布局非常容易。
我曾看到项目由于缺乏编码标准而失败——我上一家公司的花括号战争是导致团队崩溃的原因之一。
我发现最好的编码标准不是团队中某个人制定的标准。我在我们的团队中实现了IDesign(点击这里)创建的标准，这可以让您远离任何类型的怨恨，如果您试图实现自己的"标准"。
快速提到代码样式的强制执行器(单击此处)，这对于在Visual Studio中突出显示不符合性非常有用。
我们的编码标准列在我们的程序员手册中，这样每个人都可以很容易地参考它们。它们之所以有效，仅仅是因为我们已经从所有团队成员那里得到了认可，因为人们在代码审查期间不怕提出标准和样式问题，而且它们允许一定程度的灵活性。如果一个程序员创建了一个新文件，而她更喜欢将括号放在与if语句相同的行上，这就为该文件设置了标准。将来修改该文件的任何人都必须使用相同的样式来保持一致。
我承认，当我第一次阅读编码标准时，我不同意其中的一些标准。例如，对于如下所示的函数声明，我们使用特定的样式：
2
3
4
5
6
7
8
9
10
11
12
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>
}我以前从未见过，所以一开始我觉得这很奇怪和陌生。我的直觉反应是，"好吧，那太蠢了。"现在我已经在这里呆了一段时间，我已经适应了风格，并且很欣赏我如何快速理解函数声明，因为每个人都是这样做的。
SypFoT的JTest对于Java来说是不错的。
Do you have coding standards?
What does it cover?是的，它有命名约定，if之后有强制大括号，而…，不允许警告，建议32/64位对齐，不使用幻数、头保护、变量初始化和格式规则，这些规则有助于保持旧代码的一致性。
Is it being followed by everyone?
And what do you do (if anything) to make sure everybody is following the standard?大多数情况下，获得团队协议和一个稍微轻一些的编码标准(少于20条规则)帮助我们实现了这一点。
How it is being enforced ?
软，我们没有编码标准的警察。
- 审查时检查标准的应用情况。
- 我们有提供标准样板文件的模板文件
我们有一种宽松的标准。可能是因为我们无法就"在那里放多少空间"、"在语句后或在下一行放我的左大括号在哪里"等问题达成一致。
但是，由于我们有针对每个专用模块或组件的主要开发人员，以及可能在这些模块中工作的其他开发人员，因此我们有以下主要规则：
"坚持主开发人员使用的样式"
所以如果他想做3个空间缩进，也可以自己做。
这不是理想的，因为它可能需要重新调整编辑器设置，但它可以保持平静：—)
哦，是的，我是编码标准警察：)我刚刚写了一个简单的脚本来定期检查和修复代码(我的编码标准非常简单，可以实现这一点。)我希望人们在看到所有这些"编码约定清理"消息后都能收到消息：)
我认为查看编码标准的最佳方法是根据您希望通过应用实现的目标，以及如果应用不当可能造成的损害。例如，我认为下面的内容很好；
- 记录并提供单元测试，说明使用给定接口到给定例程或模块的所有典型场景。
- 尽可能使用以下容器类库等…
- 使用断言来验证传入的参数和返回的结果(C++c++)
- 最小化所有变量的范围
- 通过方法访问对象成员
- 在malloc和free上使用new和delete
- 使用指定的命名约定
我不认为在这之外强制执行样式是一个好主意，因为不同的程序员可以有效地使用不同的样式。强迫程序员改变风格可能会适得其反，导致浪费时间和降低质量。标准应简短易懂。
我从未见过一个项目因为缺乏编码标准(或对它们的遵守)而失败，甚至对生产率有任何影响。如果你花时间强制执行它们，那你就是在浪费金钱。有很多重要的事情需要考虑(比如代码质量)。
为那些喜欢遵循某些东西的人创建一套建议的标准，但不要这样做。