Introduction

Best practices in Software Development is the right way to create good quality software and nowadays the developers/architects/managers are more consciousn of it or should be!

There are many of different tools for measuring the quality of software development, NDepend is one of these tools.

This purpose of this article is to show the analysis done by NDepend and the main focus is on queries and rules, metrics and dependency graphs, but NDepend has more features.

Description

NDepend is a Visual Studio static analyzer: analyze layering, specify design rules, plan refactoring, compare different versions of the code, software metrics, dependency graphs, dependency matrix, declarative code query and more!



There is a trial version for 14 days, we can get it here and there is a Visual Studio Extension that can be found here.

This tool will analyse the DLL output from the project and at the end it allows showind various metrics, graphics, diagrams and rules. Here are what the analysis by NDepend can tell us:

This article will use an Azure Mobile Service as a demo project, but could be another project type.

After opening the project, we should attach the NDepend project to the Azure Mobile Service project as in the following:



After attaching the project, we can choose the output folder and which DLL we want to analyse as in the following:



For help understanding each DLL, here is an overview:

Note: For help in development, the Pcl contains the dtos file from the Service, but these files are “added as linked” and use directives (#if !PCL #else #endif) to change the names and to remove the base class from dtos (each dto is an EntityData).

During the analysis we can see the analysis error list as in the following:


Is a little strange to have this message.

WARNING: No application or third-party assembly found in the directory {C:WINDOWSMicrosoft.NETFrameworkv4.0.30319WPF}.

Because we are analyzing an Azure Mobile Service and there is nothing related to WPF. It makes sense to me for a WPF project but not for this project.

After the analysis, it shows a window that allows choosing what we want to see as in the following:



But after this choice we can see the other options, using the Visual Studio menu as in the following:



All output can be seen in Visual Studio, but after the analysis, an HTML page will be opened in our default browser that contains an overview about the output.

Yes, there are two ways to see the results, in a browser and in Visual Studio. This is a good thing for managers, for example.

See the output in the project folder, the project look like this:



In the browser it looks like:



See the output for this demo here.

In Visual Studio, it is recommended to open the dashboard, because it contains an interesting overview.



This overview allows making some conclusion about the code, for example this sample has 81,77% of comments and that is not bad. The graphics don´t have so much information because the first time we ran the NDepend for this project.

To understood the metrics in the dashboard, see this reference.

Note: Code Coverage by Tests is empty because it is necessary to import this information. NDepend can import coverage data from:

The Code Rules section has some violations, rules that are okay and inactive. And there is one rule that should be seen, because there is a Critical Rule Violated! Really?

Let's see it!

We can click in “Critical Rule Violated” and a window will be opened.





The rule violated is “Avoid having different types with the same name” and we can click in the “Avoid having different types with same name” to see more details. And in the right windows we will see that there are two classes with the repeated name, see it in Solution Explorer.



It is true, it is uses the same name in different DLLs, but these DLLs will never be used together and the NDepend should be smart enough to understand that these types are not used in the same context.

It is possible to see the query used to verify this rule.



The question is, can I change this query to support this specific case?

Yes, we can change the query used and should create the query to support this.

Later we will see a simple case where we will change the query.

Let's see another violation, for it click in left menu:



It is possible to filter to see, for example, the Rules Violated, here is the list:



There are rules that should be fixed, for example:

And others…

But there are rules that do not make sense, for example:

Instance fields should be prefixed with a "m_": some developers use the keyword “this” and other uses “_” as a prefix for the field name.

And the question is, why “m_”? This reference helps in that response and we can change it for that we want!



With it, it is very simple to change the rules for what we want!

There are more queries that need to be changed, another example is:

See more about change queries rules here and here.

NDepend generates a Dependency Graph, that is very interesting, Visual Studio Ultimate has this feature too. Here is the result for this project:



This graph should be clean, if it shows many connections and looks confusing then that means your code has many dependencies and maybe something is not okay. If you are using dependency injection your graph will be clean and beautiful.

Note: This project doesn´t use DI, but it is a small project and for that reason does not look confusing and shows that all is okay.

NDepend has more diagrams: Dependency Matrix, Treemap Metric View and Abstractness vs. Instability, but they are complex, because in a first attempt is not easy to understand what they mean.

See the complete list of features here.

For finalizing, it is important to define all options related with this tool. For example, define when the NDepend report should be done.




See more about it in this reference: Rules Execution Options.

Conclusion
In conclusion, NDepend is a great tool for analyzing the quality of the code from .Net projects. In this article we only generated twice the reports but for a real project it can be useful for following the metrics, violated rules and so on. The possibility of editing the queries rules is a plus for this tool.

See also