NDepend: The tool that each .NET developer, technical lead or architect should have

Since the last year, it came to my attention a great tool that I hope I should have 17 years ago when I started developing in .NET. As a developer one of the things I like to focus the most, its that actually the code that I develop that I can understand it later, or that other developers can understand it later, and that can be achieved not only with good comments, but also writing the code in a good manner.

Doing so its not an easy task, during years different vendors have released tools to analyze code from both the semantic and the architecture point of view.

Tools like FxCop and the visual studio static code analysis are things from the past, now there are better vendors than Microsoft itself in this aspect. From the semantic point of view, I see no doubts Resharper its the main leader. It allows us to refactor the code, correct semantic errors, casing, etc, I just love it.

In the past it was very common on ISVs a document with coding standards, when to use pascal case, when to use camel case, etc, this is no longer the case, now every single company I know have adopted Resharper and the rules that come by default, well its true that some rules are difficult to achieve, but you can disable them if you feel they dont make sense for your project.

From the architecture point of view, there was no tool before that could do the Job, a tool that would allow architects and developers to measure the technical debt graphically, to see the complexity of your code, to calculate how long it will take to fix that method, or that entire assembly, and to provide explanation for every single rule there.

This tool is called NDepend, and No, I havent been paid to write this blog post, I just think that whenever a tool deserves it, we the community leaders out there, contribute in some manner for the tool to become known and grow as it should be.

The tool has 2 flavors, one to use in the IDE itself and one to use integrated in your build pipeline in Azure Devops formerly know as Visual Studio Team Services, VSTS.

And you can stop a build if the quality gates, fail! how cool is that? so basically your code wont get deployed until it passes a minimum set of quality gates, this is top notch!

When you run Ndepend, you can attach it to one project or all the projects in the solution and you will find something like this after running it

Basically it analyzes your code and it will you the Technical Debt, which goes from A to D, and how long does it take to fix the code to make it 0% debt. In my case 4h58m.
It analyzes also your comments to see the percentage of code that has been commented.
If you have Unit Tests it will also check the coverage of the unit tests.

And then the most interesting part its on the right side. You will see a list of issues, rules and quality gates that you must solve in order to solve the technical debt, each number its a link that will open a docked window on the IDE that shows the rule with the problem, the description, and how to fix it, amazing isnt it?

BTW, these rules are created in LINQ over Reflection types, so the rule you see in the screenshot above, its actually analyzed like this:

// <Name>Do not raise too general exception types</Name>

warnif count > 0 

let tooGeneralExceptionTypes = ThirdParty.Types.WithFullNameIn(  
   "System.Exception", 
   "System.ApplicationException",
   "System.SystemException")

from m in JustMyCode.Methods.ThatCreateAny(tooGeneralExceptionTypes)  
// Make sure we don't match constructor of exception types
// that actually instantiate System.Exception.
where !m.IsConstructor || tooGeneralExceptionTypes.All(t => !m.ParentType.DeriveFrom(t))  
let exceptionsCreated = tooGeneralExceptionTypes.Where(t => m.IsUsing(t))  
select new {  
   m,
   exceptionsCreated,
   Debt = (15 + 5*exceptionsCreated.Count()).ToMinutes().ToDebt(),
   Severity = Severity.High
}

//<Description>
// The following exception types are too general 
// to provide sufficient information to the user: 
//
// • System.Exception
//
// • System.ApplicationException
//
// • System.SystemException
//
// If you throw such a general exception type in a library or framework, 
// it forces consumers to catch all exceptions, 
// including unknown exceptions that they do not know how to handle.
//
// This rule matches methods that create an instance of
// such general exception class.
//</Description>

//<HowToFix>
// To fix a violation of this rule, change the type of the thrown exception 
// to either a more derived type that already exists in the framework, 
// or create your own type that derives from *System.Exception*.
//
// The estimated Debt, which means the effort to fix such issue,
// is equal to 15 minutes per method matched, plus 5 minutes per too general 
// exception types instantiated by the method.
//</HowToFix>

Which means that if you know reflection, then you can write your own custom rules. In my case I never have to, there are plenty of rules with excellent documentation, if you cant fix one rule, you can disable it as well.

NDepend has other interesting features:

  1. Line charts with your progress over time, so whenever you add new code, you sill the chart moving up, and if the technical debt goes up with the increased code, you will see it too, and you can compare it with different baselines you set.

  2. Code visualization, it has a treemap metric which I find very handy and the dependencies graph its pretty neat.

  3. 82 code quality metrics! 82!.

  4. Coverage Data

For a full list of Features, see here

I highly recommend to give it a try, they have 14 day trials available