Using NDepend

I recently started a new job and was assigned to a project where there was quite a bit of existing code already. So as I was starting to get lost in the complexities of the solution I found NDepend and that helped me get my bearings and get productive really quick.

So what is NDepend? It’s a static analyzer, a dependency explorer, a code health monitor and much more. I’ll go though some of the features in more detail in the article.

First impressions

My first contact with it was getting the license and installing the software. It’s not the most straight forward process definitely not a one-click install but I think the target demographic for the application should not just have any issues . You have the option to use the app as a Visual Studio Extension or as a standalone application outside of Visual Studio. I definitely recommend the Visual Studio extension since it feels a lot nicer to see and use the reports in context.

Once installed and with a solution open, just use the NDepend menu to analyze your solution. When it’s done you will get a very nice interactive dashboard with all sorts of information about your solution ranging from lines of code to code coverage to code rules. It’s really nicely done and a great starting point. Bonus points for the web view of the dashboard that you or your boss (?) can explore outside of Visual Studio if need be.

Features

Code rules
Visual studio analyzer found 355 warnings using all rules setting while NDepend got 1300 violations (oups). I don’t have much previous experience with Code analyzers but this looks promising so far.

CQLinq
This seems the perfect segue into, you will quickly notice that Code Rules and pretty much everything on the dashboard is backed up by NDepend’s code query language called CQLinq since it’s built right on top of LINQ for quick and easy rule authoring. Using this, you can write your own code queries and implement your own code quality checks and warnings - with full Intellisense and Autocomplete I might ap
For example, in the project I am working on we are using a convention based MVVM framework, which makes it important for ViewModels to be properly named in order to be picked up by the convention managers. This is definitely no something that can be picked up by a compiler but it’s right up CQLinq’s alley:

warnif count > 0 

from t in Application.Types where 
   t.InterfacesImplemented.Any(i=>i.Name == "INotifyPropertyChanged")  &&
   !t.Name.EndsWith("ViewModel")
 
select t

Simple and efficient./\

DependencyGraph
I found the dependency Graph to be very useful, especially in my position as a new developer on a relatively large code base (40+ projects). It helped me quickly understand the patterns and relationship between various libraries. Definitely one of the features I’ve used the most so far and with great success

Trends
Last but not least, you can create and attach the NDepend analysis to the solution which will allow you to monitor the evolution of the codebase, observe trends and compare reports from various points in time. If for whatever reason not all team members have NDepend, or you don’t want to include this in your repository, you can easily ignore the project with a simple gitignore rule NDependOut
*.ndproj

Conclusions

I’m very quickly getting hooked on NDepend even though I feel I barely scratched the surface of what it can do. I think it’s an incredibly powerful tool that is capable of bringing real value to and improvements to your code.

It’s not a basic tool, there is a lot of great functionality but you need to invest a bit of time to get the most out of it. In the end I believe it’s definitely worth it and I will totally continue to use it in all my projects.

Worth noting, that it’s not free tool and while it might seem a bit steep for the occasional developer, I think the true value will come in an enterprise environment, with large teams and large code-bases and in that context the price does not look that bad.