A while ago, I received an e-mail from Patrick Smacchia, offering me a license for NDepend and asking me whether I could try it out, give some feedback and if I liked it, maybe I could blog about my experience with NDepend. Because I was already subscribed to the RSS-feed of Patrick’s blog, I knew about NDepend and how it could help developers write better code. I like trying out stuff like this, but somehow I hadn’t found time to install and properly test it. I was already using Visual Studio’s Code Analysis (FxCop) and StyleCop to analyze my code and improve its quality, so I never had the right incentives to use additional tools. But it would be rude to just say no to Patrick, so I decided to give it a try.
After installing it (which just means downloading: NDepend is a portable application that doesn’t really have to be “installed”), I started Visual NDepend (the GUI version of NDepend) and was greeted with a start page that looks like the Visual Studio start page. I decided not to just jump in and try stuff, but to first watch some of the screen casts and tutorials on the NDepend website. And I’m glad I did. After trying to analyze some of my projects, I discovered that NDepend produces a lot of data, reports and graphs that only make sense after you have learnt what it all means. This is a tool that you have to learn how to use and how to interpret its results. The user interface is very flexible, but also a bit overwhelming. But because I don’t really have an idea how I would design a UI for an application like this, I can’t really criticize it.
Comparing it to FxCop and StyleCop is not really fair. There is some overlapping functionality between the 3 tools, but NDepend offers a lot more. First of all, FxCop and StyleCop just analyze your code according to fixed rules and the result is a bunch of errors and warnings. NDepend can also be used like this, but the rules are not fixed and are defined in CQL, a query language that looks and feels like SQL, but allows you to query code constructs. The advantage of this approach is that you can write ad-hoc queries to gain insight in your code (or someone else’s assemblies). Here’s an example of a CQL query:
WARN IF Count > 0 IN SELECT TOP 10 TYPES WHERE NbMethods > 20 ORDER BY NbMethods DESC
This query will generate a warning if your code has classes (and structs) with more than 20 methods. All the built-in rules are written as CQL queries, which you can just modify (or you could just create additional rules).
Another area of analysis that NDepend offers that FxCop and StyleCop do not have is the visual views of your projects. There’s a metrics treemap that shows the proportions of different metrics of your project (methods, types, fields, …) and there are 2 ways to show dependencies: a dependency graph and a dependency matrix. While the dependency graph looks familiar and very graphical, it fails when there are too many elements and dependencies. This is not a failure of NDepend, but just a limitation of dependency graphs in general. Dependency matrices on the other hand are great to understand dependencies, even when there are a lot of elements, but they are less intuitive and you have to learn how to use them and interpret what you see.
My conclusion is that NDepend is a great tool to analyze your code and improve its quality, but it takes getting used to. You have to learn how to use it and how to interpret the results you get. I feel like I have just seen the tip of the iceberg. NDepend also contains a console-application, and can be automated and integrated in your build process (MSBuild, NAnt, …). It has add-ins for Visual Studio and Reflector, and can be used to compare different versions of a code base (for example: to see if compatibility is broken).
If you want to try it yourself, I suggest you first watch the screen casts, download NDepend and start analyzing some of your projects. Another suggestion I have is to start reading Patrick Smacchia’s blog, because he has written about some cool things you can do with NDepend. He also explains how he has analyzed some existing .NET applications (Paint.NET, NHibernate, SharpDevelop, …) and even how he uses NDepend to find what has changed between different versions of the .NET Framework BCL.