We have 3 years old solution (.sln) with about 20 projects (.csproj). It is reasonable to start using FxCop and/or StyleCop? Maybe we should use it for several small projects first but not for whole solution?
It would be good to see some experienced answers.
Thanks.
EDIT: We are using TeamCity for continuous integration. And we have no possibility to use ReSharper. :( CodeRushXpress only.
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 :)
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:
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.
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!
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.
