c# - 实施和执行编码标准

Question

我的团队（我是其中最新和最初级的成员）在大约 1 年的时间里从 3 名开发人员增加到 9 名开发人员。我们的主要产品的复杂性增加了，我们即将对 Silverlight 进行为期一年的移植/重写。过去没有强制执行特定的样式/标准。

我向我的老板建议，现在是实施这些标准的好时机。我把IDesign 的文件传给了他，他很喜欢这个主意。他有2个顾虑。

这是一个需要吸收的大文件。我的想法是为我们可能遇到的最常见项目开发一个精简的备忘单，并理解 IDesign 标准是“大师”，并且应该查看精简版本中未涵盖的任何内容在“主”文档中。
执行此操作的最佳方法是什么。这不是试图发号施令的问题。这是一个试图让人们习惯于开发特定标准的问题。团队中至少有 2 个人已经发展到现在的非标准几年了。为了解决这个问题，我想看看是否有一个工具可以配置为强制执行这些标准，或者至少在编译时或设计时警告“违反”标准。我找到了 Microsoft 的 StyleCop，但据我所知，它是不可配置的，并且设置为遵循 Microsoft 的标准，与 IDesign 的标准不完全吻合。

任何关于工具或我正在研究的方法的输入将不胜感激。

score 10 · Accepted Answer

ReSharper、FxCop/StyleCop（至少有一种为 FxCop 定义自定义规则的方法）、清晰的代码指南和每月审查的组合应该可以为一个由 9 人组成的团队完成工作。如果有人违反规则，您将别无选择，只能使用鞭子:)

score 6 · Accepted Answer

定期的代码审查将是一个好方法......

我发现开发人员对有关特定标准的面对面讨论反应更好，而不是仅仅将其留给工具。

将工具与代码审查一起使用应该很好。

score 4 · Accepted Answer

很难夸大编码标准的重要性。关键是你应该有一个每个人都能快速阅读和理解的一致的代码库。你选择哪一套标准并不重要（只要每个人都注册）——但如果你选择一个被广泛使用的标准，那么更少的开发人员将不得不调整他们的风格。Microsoft 类库开发人员设计指南是我最喜欢的（并且对 ReSharper 非常友好）。

我的一位同事 ( Howard van Rooijen ) 和他的开源团队正在为 ReSharper 开发出色的 StyleCop，它通过在您键入时突出显示它们来实时显示样式违规！最近发布了一个强烈推荐的版本。

score 4 · Accepted Answer

我在目前的公司（多个项目的小型开发人员，每个项目有 1-6 名程序员；我们主要是 C++，但我想答案仍然适用）获得对编码标准的认可的经验笔记：

代码审查备忘单是个好主意。为您的组织量身定制（例如容易忽略或出错的内容），并随时更新（每月一次，回来删除以其他方式强制执行的内容）。如果你有一个 wiki，如果可以的话，请为每个点包含指向“为什么”的链接！

拆分您的评论。有些提交请求正式审查，有些则没有。我们使用几种类型：

Mini-Design-Doc 评论，其中一个简短的（通常是 wiki 上的一页或两页）在实施开始之前由小组评论。非常适合及早发现“重新发明轮子”。
有指导的热情评论，一个或多个同行在提交之前与原作者坐在一起（非常适合传播专业知识，让合作社/实习生跟上进度）。原作者往往比审稿人发现更多的问题。=)
正式的提交后冷评审，没有指导的人（除了签入评论和任何文档）评审代码。这往往会揭示逻辑或错误处理问题，以及边界错误。

自动化和推送，不要拉取有用的信息。我们从我们的构建服务器邮寄报告——它通常在每次提交时构建一次（取决于它的繁忙程度）。这些报告可以包括例如当前 Gimpel PC-Lint 运行与上次运行之间的差异。这解决了“信息过多”的问题：您只会得到您可能负责的警告/错误以及描述。当信息范围缩小且易于理解时，人们将其用作学习工具。

这一点我怎么强调都不为过：不要为小事出汗。（请参阅奇妙的 C++ 编码标准书的第 0 点。）

将您的编码标准分成两个或更多部分，一个“必需”和“推荐”部分——让人们可以在闲暇时阅读推荐部分，并保持所需部分较小。
在审查时，明确描述现在真正重要的东西，以及不重要的东西。例如，对于我们的“热情审查”：括号放置和命名不一致明确地“稍后修复”，因为我们不想使人们在提交前审查之前所做的任何测试无效。逻辑错误是“现在修复，在提交之前”。错误处理不一致或丢失的情况各不相同。如果您要求人们立即修复甚至是微不足道的违规行为，您会感到不满。

最后，鼓励参与并随着时间的推移改变你的编码标准。（这是 wiki 可以发挥作用的地方。）如果有人有正当理由不遵循标准（要么他们有更好的东西，要么遵循的 PITA 太多），倾听并做出回应。如果人们真的积极地为标准做出贡献并理解标准，而不是仅仅接受标准，你会得到更好的回应。

score 3 · Accepted Answer

3

StyleCop 将是一个很大的帮助。

于 2008-12-04T20:29:00.447 回答

score 1 · Accepted Answer

试试 ReSharper，它可以将你的代码格式化为你的风格。甚至可以立即重新格式化整个解决方案。

score 1 · Accepted Answer

谢谢大家的建议。我很想听听更多。碰巧的是，当我按照Ilya Ryzhenkov的推荐研究 Resharper 时，我碰巧重新下载了 IDesign 标准，该标准以 zip 文件的形式提供，其中包含指向此博客条目的链接。好的部分是它默认为我想要使用的标准。它很便宜（如果你不捐赠，可以免费阅读）而且我很可能是Code-Rush的忠实粉丝！和 Refactor，所以我已经加载了 DXCore！

score 1 · Accepted Answer

我刚刚写了一篇关于一起使用 ReSharper 和 StyleCop 的博客，并通过持续集成（使用 NAnt）来执行它。

http://www.robertbeal.com/archives/47

看看你是怎么想的。它对我们非常有效。如果引入了单个代码违规，目前我会失败构建一些抱怨。虽然我们确实有成千上万的违规行为（主要是在旧的遗留代码中），所以我的回应是清理其中一个，那就是代码应该变得更好而不是更糟。

我收到了一次回复，希特勒的夜间构建失败： http ://www.youtube.com/watch?v=Azl4nqLn4-Y

score 1 · Accepted Answer

找到比这更短的东西。开发人员要记住的东西太多了，期望他们记住的不仅仅是一页规则是浪费时间。即使你给他们一张备忘单，除非那是官方的且唯一的文件，否则你最终只会让开发人员为其余部分发明自己的风格。

遵循一个简单的约定比不遵循一个大而复杂的文档要好。

顺便说一句，您是否确保从团队中获得适当的帮助？

几乎我见过的所有代码标准都规定了一些愚蠢的东西，比如所有 if 语句必须包含大括号，这会破坏像

public bool compare (Object other){
  if(other == null) throw new NullPointerException("You twit, don't give me a null pointer");
  if(!(other instanceof CustomerObject)) throw new UnsupportedArgumentException("Give me the right argument, dammit");
  ...

因为这样的东西现在占用了三行，因此不被写入（或者如果写入，阻止程序员弄清楚该方法在做什么）。

score 0 · Accepted Answer

如果您的团队有一个持续构建（例如使用Hudson），您可以通过使构建失败或在有人提交违反样式准则的更改时使其不稳定来强制执行样式约束。Hudson 有一个Violations插件，可以与 Checkstyle 和 StyleCop 等工具一起使用。

score 0 · Accepted Answer

在不知道您的配置管理设置是什么样子的情况下，我会说您应该首先寻找与您的版本控制系统集成的工具，以便在代码提交到存储库之前评估代码。我已经使用我们的 SVN 设置完成了此操作，并且也看到它使用 CVS 完成...它在一定程度上是有效的，因为它迫使开发人员提交“正确”代码并保持您的存储库整洁。如果用户没有在提交消息中提供特定信息（即错误编号、项目任务等），则一个简单的示例是拒绝提交。

除了工具之外，您还必须找到一种方法来向开发人员描述编码标准的价值。听起来很简单，但到目前为止，这对我来说是最困难的部分。向开发人员表明，在维护代码库方面，一点点努力可以大有帮助。

score 0 · Accepted Answer

在我们公司，我们使用 C# 的参考卡。参考卡使用 2 张幻灯片在 Powerpoint 中制作。前页和后页（2 页打印）。每张幻灯片有 3 列（报纸设置）。在每列之间制作 1 厘米的白色以实现折叠。

将公司完整编码指南中最重要的方面放在 2 张幻灯片中（例如，我们有：编码风格、命名空间和解决方案结构、命名约定）。

您选择了 IDesign 的开箱即用编码指南。也许你更容易熟悉 MS 编码风格，但这是你的选择。大多数开发人员都熟悉 MS 指南，因此更容易熟练。

score 0 · Accepted Answer

使用 TFS 和 VS 2010，以及 ac# base，我们这样做：

我们使用未经编辑的 idesign 标准作为我们的纸上代码标准。

我们维护一组代码分析和样式警察定义，我们在零容忍的发布版本上运行这些定义。

我们还维护了一个兼容的 Resharper 根定义，允许开发人员在使用它时快速格式化他们的代码以设置样式。这简化了他们的工作流程，因为他们不再需要等待来自构建时检查的 SA/CA 警告。

我们允许开发人员覆盖根定义。

然后在审查过程中发现并解决这两个层未发现的标准冲突。在评论中找不到的东西在代码维护中找到。

c# - 实施和执行编码标准

13 回答 13

Related

Reference