我将着手更新我们的编码标准文档，并且我正在考虑以比通常更高的水平编写它们。我们有相当数量的开发人员来来往往，他们通常具有中等技能水平。我想消除低质量的“绒毛”部分......例如，“变量命名约定”等......任何真正具有可疑价值的东西，会分散文档中真正有价值的部分（由于过多的低价值内容，可能会被略读或完全跳过）。
我也更感兴趣的是确保人们不做愚蠢的事情，而不是强迫他们以某种方式做事。
我们碰巧是一家 .Net / Oracle 商店，但对于我要寻找的材料类型，我认为语言并不是特别重要。
我想知道是否有人以前这样做过并且有一些他们不介意分享的材料，或者遇到过类似性质的任何好的在线材料？
【问题讨论】：
标签： .net visual-studio
比起标准文档，我绝对更喜欢 ReSharper 工具选项。我越是专业地开发，我就越意识到编码标准文档是浪费时间，而且它们往往会消耗生产力。
代码应该是可读和可理解的。不幸的是，编码标准也不能强制执行。然而，工具至少可以强制执行命名约定并帮助发现诸如无法检查 null 或“访问修改后的闭包”等问题。
无论如何，编码标准都不应该阻止开发人员编写好的代码。我看过禁止使用三元运算符或运算符重载的文档。我还看到要求对代码进行良好注释的文档（我不惜一切代价避免使用 cmets 以支持可读代码）。在我看来，这些东西都不应该在编码标准中。
【讨论】：
根据我的经验，编码标准的实用价值与其自动测量的能力成正比。根据 FxCop 和 StyleCop 的默认规则，我们商店的部分 C# 编码标准（适合一页）说代码必须是干净的。这两种工具都可以由开发人员以及构建过程运行。
【讨论】：
MSDN 上的guidelines for class developers 有很多好素材。很多低级的东西，比如你想消除的，它肯定更实用，但值得一看。
【讨论】：
也许只有一节是关于遵循 JP 发布的指导方针的，或者代码应该以最低分数通过 FxCop，这样就可以涵盖这些内容，并且开发人员没有理由不这样做。这将在您的标准中为特定领域的指南留出更多空间。
【讨论】：