Detecting code smells with NDepend

I recently had the opportunity to play again with NDepend. From my experience in many companies the developers, even if they find NDepend useful, don’t push enough the management to buy it, for various reasons: ‘we have free/built-in similar tools’, ‘it’s overkill for what I need’ and many other reasons.

The truth is that also the name might be misleading – NDepend is much, much more than ‘visualize the code dependencies’. It has evolved to be one of the very few tools in .NET space that takes code analysis, metrics and code quality analysis to a professional level.

Many people talk about SOLID principles, detecting code smells  but think that they can follow or detect them only ‘manually’ while writing code or while doing code reviews. Yes, this is possible with enough experience and care, but we live in a less than ideal world, where we have to work on other developers’ code, pressed by deadlines or other constraints.

Here is an analysis result produced by NDepend, on a real-world project, where we had used daily FxCop, StyleCop and Resharper for static code analysis (run automatically at build), all with a carefully selected set of rules, and where periodic code reviews were done after each task was implemented:

NDepend – Queries and Rules Explorer

of course, since these are the default NDepend rules, some warnings might not be appropriate for our project and some rules might be too strict.

Looking closer, we have at least 2 methods that are too complex – this is the ‘conditional complexity’ smell. One method has a cyclomatic complexity of 13 – not too much as a number, but when looking at the code, the method has an if, containing a foreach, containing an if with 4 conditions, and inside another foreach with 2 ifs and a for inside. Hard to test, hard to maintain and also difficult to understand for somebody not familiar with the code.

NDepend not only measures the complexity, but lets me control exactly how the rule is implemented and explains what the rules means:

Another example – NDepend shows a ‘Types with too many methods’ warning – we have one class with 22 methods (‘large class’ smell). This tells me that maybe that class is doing too much, maybe it violates the single responsibility principles and it might be possible to split it into several smaller classes. Again in this case I can easily configure the rule if needed:

One more example for today – NDepends warns me about 1 assembly with poor cohesion. Indeed, the entire library is contained in a single assembly having 89 types, some of which are too coupled between themselves. While a high coupling might be a good sign – the assembly has a single responsibility, on the other hand any change in one class might have ripple effects on other classes, so the cost of a change might be high.

Again it’s possible to see how this figure was computed:

Let’s see which classes are the main offenders: NDepend / Metrics / Most Coupled / Type:

This might signal some ‘god’ classes that are doing to much.
With NDepend we can visualize even better the dependencies:

that big green line shows me that we have a class that is using most other classes, and that it might have too many responsibilities.

Some developers might argue that they don’t have time to analyze all these daily, or that some analysis rules can be subjective – indeed, but they can be used as a starting point to detect problems in code.

Also, not the absolute metrics values or the number of warnings are important, but the trends – has the code quality degraded in the recent weeks? NDepend makes it possible to visualize also the trends over time, but about this maybe in a future episode 🙂

These are just a few reasons why, for a complex project, it’s worth to invest in a tool like NDepend – the built-in features in Visual Studio are limited, and it’s a good thing – Microsoft, even if they have the capacity to produce such a tool, should leave the room for third-party vendors that are dedicated for this.
A good sign in this respect is when the authors/vendor invest time to write and explain the concepts they care about: https://blog.ndepend.com/, http://codebetter.com/patricksmacchia/