views:

210

answers:

5

I have a large high quality c# framework codebase that I nevertheless want to try to improve.

  1. Is fxcop an effective tool for improving .NET frameworks? I know Microsoft uses the tool internally, but how do external users find it? Worthwhile?

  2. I already have a zillion lines of code and a well established style, can it be adapted to our style and still provide good guidance?

  3. Roughly, how long will it take to set up? Hours, days, weeks? Will I learn something useful sooner that later?

+15  A: 
  1. Yes FxCop is a very effective tool for improving .Net code bases. In addition to finding many different types of bugs (globalization, pinvoke, security, performance) it will also warn you of various style issues that violate conventions. And point out the occasional spelling error.
  2. FxCop is highly customizable. You could for instance turn off all style recomendations and enable only bug checking. That would give you immediate benefits without having to change your style at all.
  3. Really depends on how much of FxCop you enable and how big your code base is. I find that in my personal projects it rarely takes more than an hour to set up. But for a large project I would schedule a day or 2
JaredPar
re point 3, it may help to allow a day or two in terms of effort, but to spread this over a week or so of real time, it is quite hard to just sit down and get it right for a team first time.
Mark Dickinson
Thanks JaredPar and everybody else. Looks like we'll give this tool a try. We are just post release so I have some time for things like this.
Paul
BTW the code base has hundreds of classes, so it's pretty sizable.
Paul
+1  A: 

I find fxCop to be a good tool to enforce a coding standard. If you already have your own standard and you follow it consistently I don't see much reason to change, even more for so many lines of code. Setting up is pretty easy, running and fixing everything is something else.

Otávio Décio
+3  A: 

Yes absolutely. I used it for a year and a half. It spots all kinds of problems and gotchas and it's taught me a thing or two. Microsoft knows best in many cases.

Setting up is just a question of ticking a few boxes and modifying a few build scripts, well worth the effort. You will learn a lot from it if you research decisions it makes that you don't understand and remain open-minded.

Joe
+2  A: 

Hi Paul,

  1. Its Useful most of the time, not always! (you need to take it seriously only for some core issues, leaving out issues that are very particular to developing code in microsoft's style).

  2. Some of the guidance given by it is independent of style and is dependent on whether you are following good programming practices or not, so yes you can get some guidance from it.

  3. I don't think setup will take you much time, it should be couple of hours at max.

Thanks

Mahesh Velaga
A: 

A super-flexible alternative to FxCop would be to use NDepend and its Code Query language (CQL). CQL is dedicated to write code quality rules that can be verified live in Visual Studio, or that can be verified during build process and through a report. Here are a few samples of CQL rules (designed to be highly customizable):

Code refactored recently should be 100% covered by test:

WARN IF Count > 0 IN SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100

I don’t want that my User Interface layer to depend directly on the DataBase layer:

WARN IF Count > 0 IN SELECT METHODS WHERE CyclomaticComplexity > 15 AND PercentageComment < 10

I don’t want that my User Interface layer to depend directly on the DataBase layer:

WARN IF Count > 0 IN SELECT NAMESPACES WHERE IsDirectlyUsing "DataLayer" AND NameIs "UILayer"

Static fields should not be named m_XXX (Custom naming conventions):

WARN IF Count > 0 IN SELECT FIELDS WHERE NameLike "^m_" AND IsStatic

Methods out of MyAssembly and MyAssembly2 should not have more than 30 lines of code:

WARN IF Count > 0 IN SELECT METHODS OUT OF ASSEMBLIES "MyAssembly1", "MyAssembly2" WHERE NbLinesOfCode > 30

Public methods should not be removed to avoid API breaking changes:

WARN IF Count > 0 IN SELECT METHODS WHERE IsPublic AND IsInOlderBuild AND WasRemoved

Types tagged with the attribute MyNamespace.FullCoveredAttribute must be thoroughly covered by tests:

WARN IF Count > 0 IN SELECT TYPES WHERE HasAttribute "MyNamespace.FullCoveredAttribute" AND PercentageCoverage < 100

Patrick Smacchia - NDepend dev