#2782

Continuous Integration, NDepend and Code Quality

So a while back I blogged about CI and defence in depth. Since then the Service Factory team has had time to start evaluating the results of our latest defence in depth tooling.

As a Lead on Service Factory one of the things I’m responsible for is code quality. Obviously the best way to do this is to be in the code as much as possible, writing new features and fixing bugs. What I like is tools to point out where to go and look for issues. Problem areas of the code that deserve my attention.

Lots of people use FxCop to check for common programming mistakes as well as to reinforce stylistic and naming rules in their codebase. We’ve been running this for a while and after an initial drive to get the code passing the majority of FxCop’s rules it’s proven a good way to add some consistency to the code and prevent those common errors creaping back in. No surprises there. I’ve been using FxCop for several years and have always had good results from it (see footnote). 

So how do you take it to the next level? FxCop’s rules highlight cosmetic and localized coding issues. What would be even more useful is to get notified of areas of high complexity, high coupling. NDepend is a tool that does just that. It generates reports detailing things like coupling and cyclometric complexity. You can also write custom queries, for example return the methods with the highest complexity and lowest number of methods (classes with overly complx methods for refactoring) or classes with the highest coupling and most methods (classes what do too much).

You can find out more about NDepend at http://www.ndepend.com/. There’s example reports to look at and you can download a trial version and run it on your latest build. I can pretty much guarentee it’ll tell you some things you didn’t know about the code your team has been working on!

Currently I’ve only start using NDepend to look for hot spots in the code; lengthy or overly complex methods, methods with lots of parameters and the like. I’ll be blogging more as we start looking at dependencies and comparing changes in metrics with baselines.

Note: I’ve heard people tell me that they don’t like FxCop because it give them too many false positives or has rules they don’t agree with. I say that’s fine. It’s easy to customize the tool and turn off rules you don’t like. I tend to turn on additional rules over time as I clean up the code.