我们应该在成熟的项目中开始使用FxCop和/或StyleCop吗？

Question

我们有3年的解决方案（.sln），大约有20个项目（.csproj）。开始使用FxCop和/或StyleCop是否合理？也许我们应该首先将它用于几个小项目，而不是整个解决方案？

看到一些经验丰富的答案会很高兴。

感谢。

编辑：我们正在使用TeamCity进行持续集成。我们没有可能使用ReSharper。 :(仅限CodeRushXpress。

Answer 1

是的，你应该，但要慢慢。

获取ReSharper的副本，安装StyleCop，并获取StyleCop for ReSharper插件，设置您想要使用的规则，从那时起，您打开的每个文件都会充满摇摆的蓝色线条，告诉您哪里有东西很糟糕。

如果你只修复它们，一次只修复一个文件，你最终会得到一个干净整洁的项目，而不需要说服你的老板让你花3个星期来完成你的项目，什么都不会导致可以填充时间！

获取干净的代码就像重构一样，如果你尝试一次完成整个项目，那么你最终会陷入困境：）

Answer 2

FxCop / StyleCop 的替代或良好补充是使用商业工具NDepend。使用此工具，可以通过LINQ查询编写代码规则 (namely CQLinq)。 免责声明：我是该工具的开发人员之一

默认情况下会提出超过200 code rules，其中包括设计，架构，代码质量，代码演变，命名约定，死代码， .NET Fx用法 ......

CQLinq致力于编写可以verified live in Visual Studio或verified during build process and reported in an HTML/javascript report的代码规则。

CQLinq相对于FxCop或StyleCop的优势在于，可以直接编写代码规则，并立即获得 结果。建议设施浏览匹配的代码元素。具体来说，这看起来像是：

Answer 3

我刚开始在我的个人项目中使用StyleCop，并且需要花一点时间来处理所提出的“问题”。

我建议您在文件样本上运行StyleCop并在启动之前分析结果以进行任何更改。

例如，默认情况下，StyleCop会抱怨所有方法（公共和私有）缺少方法文档。现在，我无法为您解答这个问题，但是您需要决定是否希望私有方法拥有完整的文档（两种方式都有参数）。但是你需要决定一种方式。你不希望用一种方式进行6个月的改变，然后决定你想要另一种方式。这要么会导致你做出不必要的修改，要么必须重新审视你认为已经完成的代码。

一旦你对StyleCop的设置做了必要的调整，然后在你的代码库中放松一下 - 一次一个项目。

Answer 4

关于FxCop，是的，使用该工具是一个好主意，无论您是在新项目还是现有项目中。与StyleCop非常相似，您可以运行该工具并查看输出。与StyleCop不同，FxCop适用于编译代码，而不是源代码。

起初可能会让人不知所措。一个好主意是关闭所有规则组，然后重新运行该工具以获得空白。一次启用一个组，解析显示的任何消息，或者如果它们不适用于您，则关闭该组中的特定规则（默认规则作为一个整体非常广泛，并非全部适用;您需要自定义规则集满足您的需求。）

最后，您将通过实施适当的修补程序或有选择地禁用无关的规则来解决所有邮件。

作为一项规则（没有双关语意）我认为安全和性能小组是好的开始。命名规则是主观的，可能与您自己的约定冲突。如果是这样，请关闭它们。流动性和全球化也是主观的，取决于您的需求。至于其余部分，你可以自己做出结论！

Answer 5

根据解决方案的创建方式，集成（以及这些工具报告的修复问题）可能需要花费大量时间，因此我认为逐个集成项目是您应该采用的方式。

修改：

除了Ed Woodcock的回答：你可以配置SyleCop（我也打赌FxCop）在每个VS版本中自动运行他们的检查。使用此功能，您可以逐个启用所有项目的检查，并在常规开发期间修复所有警告（也可以配置这些工具以生成错误）。

Answer 6

取决于：

• 更改有效的代码没有任何价值。
• StyleCop编码样式可能与当前代码中的样式不匹配。
• 如果您尝试让当前代码通过FxCop和/或StyleCop，则可能会引入错误
• 许多FxCop规则很少或根本没有价值，除非第三方再次编写代码你的dll。
• 使用检查工具是没有意义的，如果你忽略它的101个警告，因为你永远不会发现你关心的那个重要的警告。

我认为这可归结为可能减少维持当前代码库的成本与获取代码库以通过代码库的成本相比检查工具。更一致的代码库将具有更低的维护成本，但如果您对代码库进行了大量更改，那么这只是值 。