StyleCop – Microsoft's Style Enforcement Tool for C#

强制编码风格是一个长期被热烈争论的话题。人们不仅为团队应该遵循何种编码风格而争论不休，同时还要争论究竟是否应该确立一个标准的编码风格。现在，微软发布了 StyleCop，这是他们在内部使用的一个编码风格强制工具，微软的这一举措无疑将起到推波助澜的作用。

StyleCop，也即所谓的微软 C#源代码分析器（Microsoft Source Analysis for C#），用途和 FxCop 相似，只不过作用对象是源代码。此外，它和 FxCop 一样是源于微软的内部工具，在发展到一定程度之后，微软觉得对其他人也有 用，于是被公开发布。不过，StyleCop 的自定义程度不如 FxCop 那么高。

Source Analysis 的最终目标是允许你生成优雅、一致的代码，让你的团队成员和其他查看你代码的人容易阅读。为达到这一目的，Source Analysis 不允许它的规则被过多的配置。Source Analysis 使用一种统一的方式来处理代码风格、布局和可读性规则。你很可能并不认同所有的规则，甚至会发现某些规则并非如你所愿。然而，在微软内部 使用这个工具的大部分团队在经过短暂的调整期后，都能够欣然接受 Source Analysis 强制要求的这些规则，甚至开始认为如果不使用这种风格来编写代码，就很难阅读。

Jason Allor 声称由这个工具所强制要求的大约 200 条规则与 Visual Studio 的默认设置是兼容的。遗憾的是，他忘记提到 Visual Studio 具有 6 个完全不同的默认设置集合，其中多数与这个工具互相矛盾的。

这个工具涉及的方面包括：

• 支持文件内容
• 调试文本
• 编排元素头和文件头中的文档格式
• 元素、语句、表达式和查询子句的布局
• 行空格
• 元素、字段和变量的命名
• 大括号、圆括号、方括号等的位置
• 在方法声明或方法调用中方法参数的位置
• 关键字和操作符周围的空格
• 在类中元素的标准顺序
• 访问修饰符的使用
• 内置类型的使用

在空白的控制台应用程序上运行这些规则，会返回 9 个错误，如果你打开“Keep Tabs”设置，则会出现 16 个错误。一些规则稍显笨拙，例如要求“using”指示符必须放在命名空间内，而不是放在文件顶部。

已经有人在抱怨这个工具缺乏校正的支持。Dustin Norman 写道：

在将这个工具运行在一个较小的程序集上时，这个工具要我手动修改 561 个违规错误，而它却不能在不影响代码语义的基础上自动为我修复错误——这真的要让我崩溃了！

古老的 tabs vs spaces 争论【译者注：即代码的缩进是用 Tabs 来实现还是用 Spaces 来实现】又被提及，而且我们还不能禁用这一规则。Nick Berardi 写道：

真是开玩笑。Tabs 居然不被允许。相反，只能使用空格。这个主意糟透了，因为它会破坏语句块的布局，例如一个变量使用 3 个空格，而其他变量则使用了 4 个。无论如何，应该允许禁用类似 tab 规则这样毫无意义的规则。 如 果能够禁用这些规则，这个工具就更好了。我知道你会说他们已经够好了。但是我完全不同意使用空格来代替 tab。这是毫无逻辑可言的，或许只有在 Vi 编辑器 第一次出现从而引发了开发人员之间的“圣战”可堪比拟吧。我喜欢用 Tab 的方式编写我的代码，但它总是警告我，我的每行代码都有 tab 在其中。

同时，Daniel Stolt 也问到了关于 VB 的情况：

为.NET 开发人员提供一些额外工具总是受欢迎的——但为什么只有 C#的？代码格式的强制规则对于 VB 开发人员来说也是非常需要的。 显然，VB 代码编辑器在对关键字和操作符进行缩进和空格的处理中，已经具有自动格式化的一些初步支持，但还不够接近 StyleCop 所支持的效果。

顺便说来，我完全同意 Nick Berardi 对于 tabs vs spaces 的观点：使用 tabs 有什么问题？难道按 4-5 次方向按钮比直接指向某个位置更有某种优势？还是在源代码文件中保存 4-5 个空白字符存在着某种好处？

在支持自动校正方面确实存在一些问题，目前还没有给出解决这个问题的时间表呢。

查看英文原文： StyleCop – Microsoft’s Style Enforcement Tool for C#