Depend on NDepend

Patrick Smacchia contacted me a couple of days ago and after giving a brief introduction about himself, asked me if I could have a look at NDepend. Firstly, thanks to my ignorance, I had never heard of this tool. Although after doing a quick search, I found out that people have been blogging about this tool for more than a year now (well, that sucks!!). Secondly and I have got to be honest here, that I felt deeply honored by Patrick’s email as this is the first time I’ve been asked to review a software.

To have a quick glance:

~9mb download
Integrates with VS (2010, 2008, 2005) completely; also has a stand-alone version 
Many Metrics for code quality
Code Query Language
Dependency Matrix and Dependency Graph
Supports Silverlight 4.0
Generates (customizable) reports

I got the download as a zip file and the install process was more or less like ‘where do I need to unzip these files’. That’s it. Looking into the folder, I see a file named ‘NDepend.Install.VisualStudioAddin.exe’.

Clicked on the buttons and I was integrated with Visual Studio. Fired up VS2010, and there it is:

I opened up a solution from one of my previous blog articles to get a better understanding of NDepend’s abilities. The first thing I noticed was the ‘Yellow Circle’ towards the bottom right corner of the VS window. Just hover your mouse pointer over and you’ll get popup:

Code Query Language (CQL) is the syntax NDepend uses to decide on the code-metrics. CQL rules do a host of things on your code (automatically) like code- quality metrics, code changes, structuring, percentage coverage by tests, unused-code detection, naming conventions just to name a few. Above image says I have 13 rules violated (and I didn’t have to do a single-click – awesome!).

There’s also a CQL Explorer which contains pre-built / frequently used queries that you can run and get results instantaneously about your assemblies, classes and methods.

Clicking on any of the items on the right side brings up the Code Query Edit window which details about the issue in concern:

You can also write you own custom query in the editor window like the one below which brings up all methods in a particular namespace. The one below lists all the methods in the namespace ‘ProductModel’. You can do something super-cool like ‘Show me all public methods in an assembly having more than say 30 lines’. I went ‘WOW’.

You can get to NDepend from your code file as well:

Let’s go to the report that NDepend generates as that’ll show the main features of interest. I go back to my ‘Yellow Circle’ and click on ‘Run Full Analysis and Build Report’. Now that my report is up, we’ll go over some of the nice things it talks about the project.

First off is about the application – just some general information:

There is also a very weird looking image:

At first, it looked like my brain scan report (empty gray circles all over), but a closer look suggested that these were actually the number of methods in the classes in the projects of the application, kinda in a visual way. In my simple application, I mostly have one method per class so you see only one gray circle per block. If you open this from within Visual Studio, you can hover over the gray circles and it’ll show you the method signature. That’s pretty cool.

There’s also a dependency diagram of the entire application and its references:

Then there’s the CQL query report which details on all the warnings (the yellows) that NDepend found out:

Last was the Types Metrics. This one shows a good amount of details along with ranking when compared against some metrics.

There are more in the list and I’ve only selected a few. Finally, there’s something called the Dependency Matrix. You can get this from the NDepend menu item:

So you’re basically reading this as: 6 methods of ProductWeb assembly are using 2 (not shown) members of the ProductModel assembly. Lets drill down and see what this opens up to:

There they are – 6 methods in the _Default.cs of the ProductWeb assembly are using 2 members of the ProductModel assembly (one in ICaller and one in IProduct). It took me a little while to get used to this, but now I’m going ‘N I F T Y’. Oh and one more thing, as with the color coding – greens are members and blues are methods. Let’s do this for the blue 4 - 4 members of the Microsoft.Practices.Unity are used by 7 methods of the ProductWeb assembly. You don’t need to learn this by-heart, there’s a tooltip that appears when you hover over the numbers.

Also when you hover over the colored blocks, you’ll see nice visual tool tips giving you information about the block (more details are shown in the expanded view).

Well, these are some of the main features of NDepend. I’m sure there are others that I’ll find out as I explore more into this.

There was one issue (seemed like a bug) that I hit upon when I’m using NDepend. I have to manually dock the CQL Query Edit window every time I load a solution. Say I have it docked on the right side in this session:

The next time I open a solution, it shows up like this:

It does not seem to remember its position. Nothing major, but it’s just one of those things!

Verdict: This is one heck of a tool that developers of all sizes, shapes, regions and ages can make use of.