我们应该在成熟的项目中开始使用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查询 （即CQLinq） 编写代码规则 。 免责声明：我是该工具的开发人员之一

默认提出了200多个代码规则 ，包括设计 ， 体系结构 ， 代码质量 ， 代码演变 ， 命名约定 ， 死代码 ， .NET Fx使用 ......

CQLinq专门编写可以在Visual Studio中实时验证的代码规则，或者可以在构建过程中验证并在HTML / javascript报告中报告的代码规则。

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

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个警告，那么使用检查工具是没有意义的，因为您永远不会发现您关心的重要警告。

我认为它归结为比获得代码的基地，通过检查工具的成本维护当前的代码库的成本 可能降低。 更一致的代码库将具有更低的维护成本，但如果您对代码库进行了大量更改，那么这只是有价值的。