Last year, I was given a free professional license for NDepend and agreed to write something about it. This very simple blog post is me trying to satisfy that agreement. 
Rules
The first feature of NDepend which got my attention was the “Rules violated” pane, which looks like the image below.
You can view all these rules in the NDepend Rules Explorer — Rules such as “Avoid methods too big, too complex”, and “Boxing/unboxing should be avoided”
I think this kind of rules greatly help programmers write better code. It helps us produce more readable code, especially when used very early in a project.
An example of violations found during my explorations with NDepend was from this code from eShopOnContainers
public class CardType : Enumeration
{
public static CardType Amex = new(1, nameof(Amex));
public static CardType Visa = new(2, nameof(Visa));
public static CardType MasterCard = new(3, nameof(MasterCard));
public CardType(int id, string name)
: base(id, name)
{
}
}
Analyzing that code using NDepend produces this rules violations report:
To make those issues go away, we just need to make the fields read-only, like in this code:
public class CardType : Enumeration
{
public static readonly CardType Amex = new(1, nameof(Amex));
public static readonly CardType Visa = new(2, nameof(Visa));
public static readonly CardType MasterCard = new(3, nameof(MasterCard));
public CardType(int id, string name)
: base(id, name)
{
}
}
One good thing about the rules in NDepend is that they give explanation of why such rules exist. For example, the rule “Avoid non-readonly static fields - Immutability” has this explanation:
… Such mutable static fields create confusion about the expected state at runtime and impairs the code testability since the same mutable state is re-used for each test.
More discussion on the topic can be found here: https://blog.ndepend.com/the-proper-usages-of-the-keyword-static-in-c/
If you have programmed for so many years already, you might already know the reason why non-readonly static fields are bad. You might even have a first hand experience of its badness, so you can easily believe what NDepend is telling you.
But, as C.S. Lewis said,
“We have to be continually reminded of what we believe.”
Our limited memory prevents us from remembering everything we have experienced since we started programming. NDepend is a great tool which can constantly remind us of what we believe, or what we have experienced to be bad or good in our .NET code.
In addition to that, I would just like to say that we should not blindly follow everything NDepend tells us to follow. Tools like NDepend do not think like us humans do. There might be times when it suggest fixes that are not applicable to our application. I think that it’s best if we try to understand the reasoning behind the rules that NDepend suggests for us to follow before doing the suggested changes in our code.
Diagram
Another good thing about NDepend is that it can generate a diagram of the structure of your codebase.
Following are digrams from the simple codebase I used in a blog post on Clean Architecture vs the traditional Layered Architecture:
We can see from the diagram whether or not our codebase adheres to the architectural idea we want to follow.
Here is another diagram generated from the codebase used in another blog post of mine:
We can see in that diagram that our codebase is adhering to the Clean Architecture idea because both the Presentation (Web API) layer and the Data layer are pointing to the Domain layer.
Now, if we try to reference and use the ASP.NET module from our Domain layer (which we should not do, because the ASP.NET module is supposed to be used only in the Presentation layer), like this:
… NDepend can show that to us in the diagram (we need to uncheck the filter named “Exclude third-party code elements” to be able to see that):
The red box in the lower-right part of the diagram is the assembly named Microsoft.AspNetCore.Mvc.Core. We can see from that diagram that both the Presentation layer (CleanAspNet.WebApi) and the Domain layer (CleanAspNet.Domain) are pointing to that assembly. But that assembly is supposed to be used only in the Presentation layer of our application, because we want to follow the Clean Architecture idea in this case.
We can see from these examples that NDepend can help us find out whether or not we are violating coding principles and architectural ideas we want to adhere to in our projects.
Those are just some of the capabilities of NDepend.
You can learn more from these links:
Have fun exploring
Other NDepend reviews:
“NDepend - Keep Technical Debt And Code Quality Under Control” by Ivan Derevianko
