我们应该在成熟的项目中开始使用 FxCop 和/或 StyleCop 吗？
我们有 3 年历史的解决方案 (.sln)，其中包含大约 20 个项目 (.csproj)。开始使用 FxCop 和/或 StyleCop 是否合理？也许我们应该首先将它用于几个小项目，而不是整个解决方案？
最好能看到一些有经验的答案。
谢谢。
编辑：我们正在使用 TeamCity 进行持续集成。而且我们没有可能使用ReSharper。 :( 仅限 CodeRushXpress。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
是的，你应该这样做，但是要慢慢来。
获取 ReSharper 的副本，安装 StyleCop，并获取 StyleCop for ReSharper 插件，设置您要使用的规则，从那时起，您打开的每个文件都将充满摆动的蓝线，告诉您哪里出了问题。
如果你只是修复它们，一次一个文件，你最终会得到一个干净的项目，而不需要说服你的老板让你花 3 周的时间来完成你的项目，不做任何会导致收费时间的事情！
获得干净的代码就像重构一样，如果你尝试一次对整个项目进行重构，你最终会陷入困境:)
Yes, you should, but slowly.
Get a copy of ReSharper, install StyleCop, and get the StyleCop for ReSharper plugin, setup which rules you'd like to use, and from then on every file you open will be full of wiggly blue lines to tell you where things are bad.
If you just fix them, one file at a time, you'll eventually end up with a nice clean project, without the need to convince your boss to let you spend 3 weeks going through your project doing nothing that results in chargable time!
Getting clean code is like refactoring, if you try and do it over an entire project all at once, you're going to end up in a pickle :)
FxCop/StyleCop 的替代方案或良好补充是使用商业工具 NDepend。使用此工具，我们可以通过 LINQ 查询编写代码规则 （即 CQLinq） 。 免责声明：我是该工具的开发人员之一
超过200个代码默认情况下建议规则，其中包括设计、架构、代码质量、代码演化、 命名约定、死代码、.NET Fx 使用...
CQLinq 致力于编写可以在 Visual Studio 中实时验证，或者可以是 在构建过程中进行验证并在 HTML/javascript 报告中报告。
与 FxCop 或 StyleCop 相比，CQLinq 的优势在于可以直接编写代码规则，并立即获得结果。建议使用设施来浏览匹配的代码元素。具体来说，它看起来像这样：
An alternative or a good complement to FxCop/StyleCop would be to use the commercial tool NDepend. With this tool one can write Code Rule over LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default, these include design, architecture, code quality, code evolution, naming conventions, dead code, .NET Fx usage...
CQLinq is dedicated to write code rules that can be verified live in Visual Studio, or that can be verified during build process and reported in an HTML/javascript report.
The strength of CQLinq over FxCop or StyleCop, is that it is straightforward to write a code rule, and get immediately results. Facilities are proposed to browse matched code elements. Concretely this looks like that:
我刚刚开始在我的个人项目中使用 StyleCop，确实需要一些时间来解决所提出的“问题”。
我建议在启动进行任何更改之前对文件样本运行 StyleCop 并分析结果。
例如，默认情况下，StyleCop 会抱怨缺少所有方法（公共方法和私有方法）的方法文档。现在，我无法为您回答这个问题，但您需要决定是否希望私有方法具有完整的文档（两种方式都有争论）。但你需要决定其中一种方式。您不想用 6 个月的时间来改变一种方式，然后又决定采用另一种方式。这要么会导致您进行不必要的更改，要么必须重新访问您认为已经完成的代码。
一旦您对 StyleCop 的设置进行了必要的调整，然后将其释放到您的代码库中 - 一次一个项目。
I've just started using StyleCop on my personal projects and it does take a little time to work through the "issues" raised.
I would recommend running StyleCop on a sample of your files and analysing the results before launching in to make any changes.
For example, by default StyleCop complains about missing method documentation for all methods, both public and private. Now, I can't answer this for you, but you need to decide whether you want private methods to have full documentation or not (there are arguments both ways). But you need to decide one way or the other. You don't want to get 6 months into making changes one way and then decide that you want it the other. That's either going to lead you to make unnecessary changes or have to revisit code you thought you'd finished.
Once you have make the necessary adjustments to StyleCop's settings and then let it loose on your code base - one project at a time.
关于 FxCop，是的，无论您是在新项目还是现有项目中，使用该工具都是一个好主意。与 StyleCop 非常相似，您可以运行该工具并查看输出。与 StyleCop 不同，FxCop 适用于编译代码，而不是源代码。
一开始可能会让人不知所措。一个好主意是关闭所有规则组，然后重新运行该工具以获得空白状态。一次启用一组，解决出现的任何消息，或者关闭该组中的特定规则（如果它们不适用于您）（默认规则作为一个整体非常广泛，并非所有规则都适用；您需要自定义满足您需求的规则集）。
最后，您将通过实施适当的修复或有选择地禁用无关规则来解决所有消息。
通常（没有双关语）我认为安全和性能组是很好的起点。命名规则是主观的，可能与您自己的约定发生冲突。如果是这样，请将其关闭。移动性和全球化也是主观的，取决于您的需求。至于其余的，好吧，你自己得出结论！
Regarding FxCop, yes it is a good idea to make use of the tool, whether you are in a new project or an existing one. Much like StyleCop, you can run the tool and review the output. Unlike StyleCop, FxCop works on compiled code, not source.
It will probably be overwhelming at first. A good idea is to turn off all the rule groups, and rerun the tool to get a blank slate. Enable one group at a time, resolving any messages that appear, or turning off specific rules in that group if they do not apply to you (the default rules as a whole are quite broad, and not all will apply; you need to customize the ruleset for your needs).
At the end, you will have resolved all messages by either implementing appropriate fixes, or selectively disabling extraneous rules.
As a rule (no pun intended) I consider the Security and Performance groups good ones to start with. The Naming rules are subjective, and may clash with your own conventions. Turn them off if so. Mobility and Globalization are also subjective, and depend on your needs. As for the rest, well, you create your own conclusions!
根据解决方案的创建方式，集成（以及修复这些工具报告的问题）可能会花费大量时间，因此我认为逐一集成项目是您应该采取的方式。
编辑：
除了Ed Woodcock的答案之外：您可以配置SyleCop（我打赌FxCop也是如此）在每个VS构建期间自动运行检查。使用此功能，您可以在常规开发过程中对所有项目一一打开检查并修复所有警告（您也可以配置这些工具以生成错误）。
Depending on how solution was created integration (and fixing issues reported by these tools) could take a lot of time, so I think integration of projects one by one is the way you should go.
EDIT:
In addition to Ed Woodcock's answer: you can configure SyleCop (and I bet FxCop too) to automatically run their checks during each VS build. Using this feature you can turn on checks on all of your projects one by one and fix all warnings (also you can configure these tools to generate errors) just during your regular development.
这取决于：
我认为这可以归结为与让代码库通过检查工具的成本可能降低维护当前代码库的成本相比。 /强>。更一致的代码库将具有更低的维护成本，但是只有如果您对代码库进行大量更改，这才有价值。
It depends:
I think it comes down to the possible reduction in the cost of maintaining your current code base compared to the cost of getting the code base to pass the checking tools. A more consistent code base will have a lower cost of maintenance, but this is only of value if you are making lots of changes to the code base.