Tag Archives: NDepend

Tracking Code Base Over Time With NDepend

Recently I started out exploring NDepend. After looking into the basic stuff I wanted to explore the comparison features. Being able to report on how the quality of your code base changes over time would be very nice. Luckily, NDepend lets you do this very easily.

Let us assume you have already set up an NDepend project and finished your first analysis. I included not only the assemblies I wanted to be analyzed but also added a dotCover code coverage report (thus being able to track code coverage as well). Under Project Properties you choose the analysis result as Baseline for Comparison:


Once you have done that you sit back and wait for your code base to change. I waited a few days and luckily it did! I re-built the assemblies (which are referenced in the NDepend project so I did not re-include them) and also created another code coverage report. After that you just run a new analysis and the dashboard, in addition to giving you a brief overview of the analysis, now shows some interesting details about what changes have taken place:


In my case it informed me about:

  • increased number of lines of code, namespaces, types, methods etc.
  • a slight increase in average method complexity
  • about a decreased code coverage (I have more lines of code covered now but more uncovered lines of code were also added)
  • new rule violations

When I looked at the rule violation results there was an interesting category named API Breaking Changes. It informed me about possible problems because some public interfaces had been changed. It marked them as critical which I do not think they are (still have to find some way of ignoring certain rules). If you develop a closed product and you are analyzing all there is to it, it should not pose a problem. Would I be developing a framework that others are using, then I can see the point. NDepend has no way of knowing. But there were also some rules in there which were clearer like the one checking for changes to serializable types.

So the comparison feature is really nice. I guess if you do this analysis frequently and observe the results over time, NDepend can give you both

  • a meaningful and quick impression of your code base changes to the better or worse as well as
  • tools to find out more about the areas where the problems grew or shrank that are important to you.

Starting to work with NDepend

I got my hands on a copy of NDepend. Don’t worry, it is a legitimate professional license… NDepend is a .NET code analysis tool that offers a lot of metrics and information on your code base. Here are some of my first impressions.

It starts out easy enough. You have the choice of using it from Visual Studio (it comes with an AddIn installer), from the command line (for analysis during automated builds, I guess) or from a standalone desktop application. I chose the desktop application and was prompted to specify the code base. It analyses assemblies and you have multiple ways of importing them, including some wizards. This is were it started to get tricky because the wizardry did not work that well so I had to import the DLL’s by hand. This is a tool for the sophisticated developer and it shows already at the beginning. After I imported the main assemblies of a project I am working on, I generated my first report.

Here are a few items from the report.

I have seen NDepend before and the thing that scared me then and still scares me now is a thing called Treemap Metric View (which is presented very prominently):


It is supposed to provide you with a single visual on the complexity and state of your code base. The report provides a few other visuals on relationships between namespaces and assemblies which are nice but overly complex and too much 10000 foot view.

The main part of the report consist of results of checks applied to your code base. Don’t freak out: You will see a lot of rule violations! If you can understand it for what it is supposed to be, fine. These rules represent opinions. But they have been found to be very helpful by a lot of developers over a long period of time and thus might have become hard facts. Here are a few examples.

There is this critical warning called Types too big of which the tool found two violations, both being around 800 lines of code long. It is common knowledge that big types should be broken down into parts that each are small and ideally just do one thing. It makes your components way more maintainable and reusable but the main advantage is increased readability, in my opinion. So good job, NDepend! There are many other useful rules, like Methods that could have a lower visibility.

Rules often make use of metrics like Cyclomatic Complexity or Nesting Depth. They give you a lot of insight but they are complex and hard to understand at times.

Some rules are debatable, especially ones that are declared as Critical but only in the eye of the beholder. Yes, it is not good to have a violation of the rule Potentially dead Methods, but should it be critical? Who out there does not have unused methods or types sitting around waiting to be reenacted? An interesting one is Constructors of abstract classes should be declared as protected or private. I agree and my Resharper lets me change that in a heartbeat but is it critical issue? Rules come with some sort of source code example of the rule alogorithm which also shows comments so that you can learn more about the rule. In this case it it says the very fact is of a public constructor in an abstract class is useless. Useless is not critical, at least not to me.

I think there is a dilemma here. You need to be a sophisticated developer to correctly use and interpret NDepend. But the very fact that you are of such advanced state means that you already know what you are doing wrong and what you are doing right. The bad developer will get way more violations but does that point him in the right direction? Does that change him?

I like the tool. It gives me something so that I can get into an informed discussion about the state of my code.

Things I would like to check out in the future:

  • Baselining. Even if you do not buy into some of the rules and metrics you can see your code base evolving.
  • You can incorporate unit test code coverage result into your reports.
  • Creating own rules
  • Disabling/enabling/configuring/adjusting existing rules