A few weeks ago I was contacted by Patrick Smacchia, NDepend’s lead developer, to evaluate NDepend and perhaps spread the word about this tool. Already using SonarQube in my daily work and being focused, as a freelance software consultant, on the quality of my work, which in turn affects its reliability and the satisfaction of my clients, I gladly accepted.

So, what is NDepend?

NDepend is a static code analysis tool that, with its wide range of features, provides deep insights into code bases, empowering .NET architects and developers to make informed decisions when working with complex projects.


NDepend comes with no installer: just unzip it in your preferred folder, add the license file and that’s it! Someone might prefer to use an installer, at least to have a start menu entry, but I absolutely love this lack of installation, since I can move it freely around.

NDepend can be started in two ways: using its own user interface, called Visual NDepend (Figure 1), or directly from Visual Studio, for which a simple and intuitive installation interface is provided (Figure2).

NDepend first start
Figure 1 – Start window
NDepend Visual Studio integration
Figure 2 – Visual Studio integration tool

Main Features

The impact with the tool after the first analysis is run can be a little overwhelming for new users: lots of menus to explore, lots of reports, lots of customization options (Figure 3).

NDepend analysis result
Figure 3 – Analysis result

NDepend is a tool for programmers and power users, so it doesn’t even try to hide its complexity. By the way almost anything that is clickable comes with its own contextual tooltip.

So, what kind of information you can extract from NDepend?

Quality Gates: a Quality Gate can be seen as a PASS/FAIL criterion for software quality. A number of default Quality Gates are proposed by NDepend related to measures like technical debt amount, code coverage, etc., and it will probably be the first information your VeryBusyProjectManager(TM) will ask.

Smart Technical Debt Estimation: the technical debt is an estimation of the extra effort that we have to do in future development because of quick and dirty design choices. NDepend allows the developer to keep the technical debt monitored, providing a baselining mechanism and an estimation of the progress since the baseline.

Trend monitoring: charts reporting trends such as Lines of Code, Number of Code Rules Violated and number of Code Rules Violations, Code Coverage per Tests, Max and Average values for various Code Quality Metrics, etc., are available by default and can be displayed on the NDepend dashboard.

Metrics, metrics, metrics: NDepend comes with 84 code metrics. Some of them are related to code organization (the number of classes or namespaces, the number of methods declared in a class…), some of them are related to code quality (complexity, percentage of comments, number of parameters, cohesion of classes, stability of assemblies…), some of them are related to the structure of code (which types are the most used, depth of inheritance…) and some of them are related to code coverage (%coverage, number of lines of code covered, branch coverage…).  It also provides an intuitive metric view that organizes graphically a configurable combination of metrics, giving a quick overview about the status of the code (Figure 4).

Metrics view
Figure 4 – Metrics View

Exploring existing architectures: so, you had no time to do your UML homework and some months later you’re completely lost in your code, are you? No worries, NDepend can help with functionalities such as code dependency graph and matrix, dependency cycles detection and treemaps.


CQLinq, Code Query LINQ, is a feature proposed by NDepend since the version 4, to query .NET code through LINQ queries. All the quality checks in NDepend are executed by a CQLinq query and, as such, all the checks are customizable as well as new queries can be defined.

For example, on the project I analyzed, NDepend reported the violation of a critical rule regarding the explicit creation of a new thread.

NDepend critical rule
Figure 5 – Critical rule violation

A double click on the rule opens the “Queries and Rules edit” window, showing the CQLinq code involved:

warnif count > 0 from m in Application.Methods where 
  m.CreateA ("System.Threading.Thread".AllowNoMatch())
select new {
   Debt = 60.ToMinutes().ToDebt(),
   Severity = Severity.Critical

Just changing the severity to medium (code intellisense provided) and hitting the save button made the analysis run again, reporting this time only 2 critical violations.

For sure there could be a bit of a learning curve to get fluent with CQLinq (a previous experience writing.NET Linq queries helps in smoothing the curve), but it’s definitely worth it.


NDepend’s analysis is impressive, the number of insights on the code available by default is astounding and the fact that the rules are completely customizable via CQlinq makes it even more powerful. For these reasons, NDepend is a complex analysis tool that makes it necessary to have a clear strategy when using it. 

IMHO, NDepend is a great tool to keep big projects under control, but is probably overkill for small projects. In any case, the only way to decide if you need it or not is to try it for yourself, and see how it works out for you!

Disclaimer: Even if I received a free license to test the product, I made no promise of a good review in return, and this article is based purely on my own observations and use of NDepend.


Leave a Reply

Your email address will not be published. Required fields are marked *

Before submitting your comment, please read and accept the privacy policy. Your comment will be held for moderation and will be visible in a few hours.