【发布时间】：2011-01-28 11:48:19
【问题描述】：
我们有 3 年的解决方案 (.sln) 和大约 20 个项目 (.csproj)。开始使用 FxCop 和/或 StyleCop 是否合理？也许我们应该先将它用于几个小项目，而不是整个解决方案？
希望能看到一些有经验的答案。
谢谢。
编辑：我们正在使用 TeamCity 进行持续集成。而且我们不可能使用 ReSharper。 :( 仅限 CodeRushXpress。
【问题讨论】：
【发布时间】：2011-01-28 11:48:19
【问题描述】：
是的，你应该这样做，但要慢慢来。
获取 ReSharper 的副本，安装 StyleCop，并获取 StyleCop for ReSharper 插件，设置您想要使用的规则，从那时起，您打开的每个文件都将充满摆动的蓝线，告诉您事情在哪里不好。
如果你只是修复它们，一次一个文件，你最终会得到一个干净整洁的项目，而无需说服你的老板让你花 3 周时间来完成你的项目，什么都不做会导致收费时间！
获得干净的代码就像重构，如果你试图一次在整个项目中完成它，你最终会陷入困境:)
【讨论】：
-
是的，添加它们会杀死你一段时间 - 它会显示大量问题。
-
不可能使用 ReSharper。 :( 还有其他使用 StyleCop 的方法吗？也许是通过 CodeRushXPress？那么 FxCop 呢？
-
为 CodeRushXpress 找到 StyleCop！ crstylecop.codeplex.com/Release/… 感谢您的想法。
-
嗯，不知道。我不是 CodeRush 的忠实粉丝，我拥有 ReSharper 的主要原因是语法高亮，以及弹出的重构和纠错选项的小灯泡。 CodeRush 似乎没有。不过这里的其他一些人也在使用它，所以我可能会将他们指向那个插件：D
-
首先对单个文件使用 stylecop 来解决大多数问题，然后安装 stylecop 以进行 resharper - 否则您将被问题淹没。
FxCop/StyleCop 的替代或很好的补充是使用商业工具NDepend。使用此工具，您可以在 LINQ 查询上编写代码规则 (namely CQLinq)。 免责声明：我是该工具的开发人员之一
超过200 code rules默认提出，包括设计、架构、代码质量、代码演化 em>、命名约定、死代码、.NET Fx 用法...
CQLinq 专门编写代码规则，可以是verified live in Visual Studio，也可以是verified during build process and reported in an HTML/javascript report。
CQLinq 相对于 FxCop 或 StyleCop 的优势在于可以直接编写代码规则，并立即获得结果。建议使用设施来浏览匹配的代码元素。具体来说是这样的：
【讨论】：
我刚刚开始在我的个人项目中使用 StyleCop，确实需要一些时间来解决提出的“问题”。
我建议在您的文件样本上运行 StyleCop 并在启动之前分析结果以进行任何更改。
例如，默认情况下，StyleCop 会抱怨缺少所有方法的方法文档，包括公共和私有方法。现在，我无法为您回答这个问题，但您需要决定是否希望私有方法具有完整的文档（两种方式都有参数）。但你需要决定一种或另一种方式。您不希望在 6 个月内以一种方式进行更改，然后决定采用另一种方式。这要么会导致您进行不必要的更改，要么必须重新访问您认为已经完成的代码。
一旦您对 StyleCop 的设置进行了必要的调整，然后将其放到您的代码库中 - 一次一个项目。
【讨论】：
-
我想有一种方法可以将 StyleCop 用于来自 colution 的单个项目，但不适用于整个解决方案。谢谢。
-
@Vasiliy - 我知道您可以右键单击一个文件并从上下文菜单中仅对该文件运行 StyleCop。你可以通过右键单击一个项目来做同样的事情吗？ （我还没有在这台电脑上安装 StyleCop 来检查）。
-
刚刚安装了 StyleCop。是的，可以在文件或项目上运行。
-
@Vasiliy - 我以为你可以在单个项目上运行它，但我不是 100% 确定，所以不想做一个明确的声明。
关于 FxCop，是的，使用该工具是个好主意，无论您是在新项目还是现有项目中。与 StyleCop 非常相似，您可以运行该工具并查看输出。与 StyleCop 不同，FxCop 处理编译后的代码，而不是源代码。
一开始可能会让人不知所措。一个好主意是关闭所有规则组，然后重新运行该工具以获得空白。一次启用一个组，解决出现的任何消息，或者关闭该组中不适用于您的特定规则（默认规则作为一个整体相当广泛，并非所有规则都适用；您需要自定义满足您的需求的规则集）。
最后，您将通过实施适当的修复或选择性地禁用无关规则来解决所有消息。
通常（没有双关语）我认为安全和性能组是好的开始。命名规则是主观的，可能与您自己的约定冲突。如果是这样，请关闭它们。移动性和全球化也是主观的，取决于您的需求。至于其余的，好吧，你自己得出结论！
【讨论】：
-
非常有帮助的答案。谢谢。
根据解决方案的创建方式，集成（以及修复这些工具报告的问题）可能需要很多时间，所以我认为一个项目的集成是您应该采用的方式。
编辑：
除了 Ed Woodcock 的回答：您可以配置 SyleCop（我也打赌 FxCop）在每个 VS 构建期间自动运行检查。使用此功能，您可以在常规开发期间对所有项目逐一打开检查并修复所有警告（您也可以配置这些工具以生成错误）。
【讨论】：
-
我们有用于持续集成的 TeamCity。也许我应该在我的问题中提到这一点。
这取决于：
- 为了它而改变代码没有任何价值。
- StyleCop 编码风格可能与您当前代码中的风格不太匹配。
- 如果您尝试让当前代码通过 FxCop 和/或 StyleCop，您可能会引入错误
- 许多 FxCop 规则几乎没有价值或没有价值，除非第 3 方再次为您的 dll 编写代码。
- 如果您忽略其中的 101 条警告，则使用检查工具毫无意义，因为您永远不会发现您关心的重要警告。
我认为与让代码库通过检查工具。更一致的代码库将具有更低的维护成本，但这仅在对代码库进行大量更改时才有价值。
【讨论】：
-
我觉得这个评论传递了一个错误的事实，即工作代码是好的代码，它可能不是。好的代码有巨大的价值。 85% 的时间花在维护上，好的代码可以改善维护。更改有效的代码具有巨大的价值，而不是无效的代码！正在工作的代码可能会保留很长时间，应该记录并妥善记录。它应该遵循一套你计划在未来使用的风格和设计标准，并且比任何其他代码更容易让未来的程序员理解。