NDepend - A Dependable Static Analyzer

Two weeks ago I wasn’t so much familiar with the terms static analysis and analyzer. I mean, I heard those terms here and there but didn’t really give it a proper look. Then comes the time when Patrick Smacchia (Creator of NDepend) asked me to give NDepend a go. So I found it as an opportunity to learn about these stuffs and here I’m writing a blog about it. ‘Nuff history lessons. Let’s talk about what static analysis or analyzer really is.

Static analysis is a way of analysis your codebase without executing it. Sounds good? But what good will it do to us (developers) to analysis a codebase? Well let me go back two years ago when I was in my first job. I still remember that I was sitting in front of my PC trying to figure out how my codebase works by debugging it. Man! Let me tell you, it was a huge pain in the ass. First of all, it was a huge codebase with lots of dependencies scattered around. Again, a project that is running over two years of course have many developers working on it from different time periods. It was quite a mess there, not from the coding structure view point rather that it was handled by so many developers. Different developers have different ways of coding a codebase. For example, many developers define a private field in a class by adding an underscore (_) in front of the camel casing form of that field. Like,

private CoffeeMakerAPI _api;

Many chooses the different way, by doing the camel casing and not adding the underscore.

private CoffeeMakerAPI api;

While these aren’t actually causing any problems in your codebase but at the same time it is making your codebase messier. I remember that I asked my seniors about this issue and the answer I got was pretty much absurd, “Just use one of them!”.

Now think it from your perspective. Wouldn’t it be great if you have a tool that helps you resolve this kind of situations? Wouldn’t it be great if there is a tool that will warn you if you define a private field without adding an underscore (_) in front of it and every developer who is working on the project is bound to follow the rule? Don’t worry there are tools for doing these kind of analysis. And they are called static analyzers. NDepend is one of them. NDepend doesn’t only warn you about these kinds of naming issues but also warns you if your codebase breaks any of the object oriented design principles(SOLID) and software design patterns and practices and many more. Good thing is these patterns and practices are not the product of any rocket science experiment over the night rather these are well known and industry accepted. So far we’ve been talking about rules and regulations. But NDepend has many other options which can help you have a deep application insight of your project like dependency graph, code metrics, test coverage etc.

Now that I’ve taken and placed NDepend on the top of the mountain, let’s play around with some of its features and see if it’s really worth our time and money.

I’m working with a great code example of SOLID design. It is known as The Mark IV Special Coffee Maker. The code example was published in the book named Agile Principles, Patterns, and Practices in C# by the master of OOP design, Robert Cecil Martin (Uncle Bob) and Martin Micah. Search and download the book on Amazon if you are interested in learning how to write code in true objected oriented way

By the way you can download and install NDepend from this link given below,


You can start a 14-day free trial or buy a premium license. The installation is very easy. After unzipping the downloaded zipped file, you will have a folder that looks like this,

As you can see there is Visual Studio extension for NDepend. I’ll be demonstrating features of NDepend in Visual Studio, so I’ve already installed it with the extension installer. You can also try the NDepend.Console and the VisualNDepend exes. You will find a lots of resource on their official site on how to use these two exes.

After installing NDepend, you will have a NDepend menu in Visual Studio from where you can initialize a NDepend project for your current solution.

Clicking on the Attach New NDepend Project to Current VS Solution will start doing some analysis on your solution and this dialog box will pop up.

Also a report made out of html and javascript will be popped up in your browser,

Okay, now this is the starting point. If you scroll through the report, we will see some interesting insights of your project. Like application metrics where you can see how many lines of code have been written so far in the codebase, how many of them are useless (dead code). You can also see how many types, namespaces, assemblies are available in your solution and how much of your project is dependent on third party libraries. How much test coverage your code has and how complex your methods are? As you can see these are lots of information that you are getting just by a single click on the mouse.

I’ve talked about rules earlier and here you can see how many software design rules are violated in my example,

Although not all rules can be satisfied but you got the idea. Let’s get back to Visual Studio and see if we can fix some of these issues. Click on the option Rule > View Explorer Panel .

Visual Studio will open up a Query and Rules Explorer window. As you can see there are some ruleset ready for you. One of them is “Object Oriented Design”. Some of these predefined rules are violated in my code example. So let’s fix one of them. Its saying that Class with no descendant should be sealed if possible and showing the classes that violated the rule on the bottom right panel. If you open any of the classes, you will see that these are abstract classes and abstract classes can’t be sealed and static. So, we don’t have much to fix in here (As I told you, Not every rules can be satisfied).

In Visibility rule set, you can see that we have a warning saying that Constructors of abstract classes should be declared as protected or private.

So I’ve searched in all the classes who violated that rule and fixed them and rerun the analyzer from Dashboard again. Now the explorer doesn’t throw any warning for that issue that I was having before,

If you notice on the top right explorer these rules are merely some Linq queries (more precisely CQLinq). These queries use reflection on your codebase and give you the result based on the output.

Except for the predefined rules, you can also write your own rules. For example, let’s say that your project manager wants you to list all the protected abstract methods available in in your solution. So here is the CQLinq for that,

// Show all the abstract protected methods
warnif count > 0 from f in Application.Methods where 
  !f.IsProtected && f.IsAbstract
select new { f }

Now, you have a new rule for showing a warning if there are any protected abstract methods

Let’s shift our gear and talk about dependency graph. Here is a dependency graph of a pet project of mine called Bookish generated by NDepend.

As you can see how easy it is to have an eagle eye view of the dependencies. In the image given abode I’ve placed my mouse cursor on the assembly called Bookish.Caching and NDepend’s interactive dependency graph immediately shows all the dependent assemblies in green (Bookish.App). All the assemblies that my Bookish.Caching depends on is highlighted in blue.

View Dependency Matrix option provides the same information in a matrix form. If you hover over any of the cell, NDepend will give you some context sensitive help.

You can even have isolated graph of a selected cell just by selecting the option Build a graph made of code elements involved in this dependency

You can have test coverage of your codebase. I’m using Visual Studio Community Edition so I don’t have the option for Analyzing Test Coverage (only available in Enterprise editions) from the IDE. You can use some other coverage tools (dotCover, NCover) also to export test coverage data and use it in NDepend.

Then you can run some analysis on that data if you want.

If you are playing with the html & javascript report produced by NDepend, you may notice that there is graph called Abstractness Vs Instability. This graph simply represents the fact that the more your code is abstract in nature the more it is extensible and that is Abstractness whereas Instability represents that how well the system allows changes to it without breaking it.

If I have assemblies that are not extensible then my assemblies would have fall into the Zone of pain section (lower left quadrant of the graph). Again if my assemblies are extensible but has no dependencies, that means those are useless and they will be in the Zone of uselessness(Upper right quadrant of the graph).

As you can see in the graph the assembly called Bookish.Interface has maximum abstractness because I only have interfaces there and also has some uselessness cause not every assemblies is dependent on that.

Last thing I want to talk about is the tree map matrix view.

The squares in the graph are methods used in the assemblies. The size of the rectangle is proportional to the Line of Code in that method and the color represent the Cyclomatic Complexity of that method. Nice thing about this graph is, now I can easily see the complex methods in my assemblies and take appropriate actions against them.

Okay, if you made it this far, you are now a NDepend Ninja!!! Well, I’m kidding. Here we only just scratched the surface of NDepend. There are lot of things that I ignore for the sake of simplicity of this post. Again the fact is I’m also new to this kind of tools and learning bits and piece every day. From my perspective, NDepend is a great tool to make our developing life somewhat easy. NDepend really shines when it is used in big projects. Think of it like this, if your project is a sea, you are a floating boat in it without a sail. If you want to reach the shore, then choose NDepend as if it is your sail.