Analyzing C# code using NDepend
Introduction
Best practices in Software Development is the right way to have a good quality in Software and nowadays the developers/architects/managers has more consciousness about it or should have!
There are a lot of different tools for measuring the quality of software development, NDepend is one of these tools.
This article has the goal to show the analyze made by NDepend and the main focus are query and rules, metrics and dependency graph, 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!
http://s10.postimg.org/hxqkneujd/visual_studio.png
There is a trial version for 14 days, we can get it here and there is a Visual Studio Extension that can be find here.
This tool will analyze the dll output from the project and at the end it allow to show different metrics, graphics, diagrams and rules. Here are what the analyze of NDepend can tell us:
- Application Metric: This section gives you an idea of the topology of your application.
- Assembly Metric: This section gives you an idea of the size of each assembly within your application in terms of #IL instructions and others metrics.
- VisualNDepend View: This section illustrates the size of your assemblies, namespaces, types and methods in terms of #IL instructions. You can browse this view dynamically by clicking the Launch Visual NDepend on this Project icon in the NDepend.Project UI.
- Assembly AAbstractness vs. Instability: This section illustrate the AAbstractnessInstability principle explained in the assemblies metrics section.
- Assembly Dependencies: This section shows all dependencies between assemblies of your application in a table.
- Assembly Dependency Diagram: This section shows all dependencies between assemblies of your application in a diagram
- Assembly build order: This section gives you one of the possible build order for your assemblies. If a cycle exists in your assemblies dependencies graph, this section will report it.
- NDepend information and warnings: This sections gives you advices about your code:
- It warns you when an assembly depends on a less stable assembly than itself.
- It warns you when the visibility of a type or of a member is not optimal (in the context of the analysed application).
- It warns you when a type or a member is not used (in the context of the analysed application).
- CQLinq Queries and Rules: This section reports default CQLinq rules which have been violated. More about CQLinq here.
- Type Metrics: This section recaps type metrics in a table. A link to the documentation is provided for each metric.
This article will use an Azure Mobile Service as a demo project, but could be another project type. After opened the project, we should attach the NDepend project to the Azure Mobile Service project
http://s28.postimg.org/juxb4y4l9/ndepend.png
After attach the project, we can choice the output folder and which dll we want to analyze
http://s9.postimg.org/9st72p90v/ndepend1.png
For help to understood each dll, here is an overview:
- CustomersSample.Service is the dll output for the project that contains the Azure Mobile Service that will be deploy to the server.
- CustomersSample.Pcl is the dll that contains the entities that can be used in client apps (like Windows Phone, Windows Store Apps, Xamarin or in Tests.)
- CustomersSample.Tests is the dll that contains tests for help to understand if the service is working correctly. This project simulate a client app doing requests to the service.
Note: For help in development, the Pcl contains the dtos file from Service, but these files are "added as linked", and was used directives (#if !PCL #else #endif) for change the names and for remove the base class from dtos (each dto is a EntityData). During the analyze we can see the analysis error list
http://s11.postimg.org/3nz43kr37/ndepend2.png
Is a little strange to have this message
*
WARNING: No application or third party assembly found in directory {C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\WPF}
*
Because we are analyzing an Azure Mobile Service and there is nothing related with WPF. It make me sense for WPF project not for this project.
After the analyze, is showed a windows that allow to choose what we want to see
http://s22.postimg.org/dnsq28875/ndepend3.png
But after this choose we can see the other options, using the Visual Studio menu
http://s4.postimg.org/d4bt4b7wt/ndepend5.png
All output can be seen in Visual Studio, but after the analyze, an html page will be open in our default browser that contains an overview about the output.
Yes, there are two ways to see the results, in browser and in Visual Studio. This is a good thing for managers, for example. See the output in project folder, for this project look like this
http://s30.postimg.org/4kisdb44x/ndepend8.png
In the browser it looks like it
http://s30.postimg.org/4yu8750vl/ndepend9.png
See the output for this demo here.
In Visual Studio, is recommended to open the dashboard, because it contains an interesting overview.
http://s12.postimg.org/5yh519i3x/ndepend7.png
This overview allow to make some conclusion about the code, for example this sample has 81,77% of comments that is not bad. The graphics don´t have so much information because was the first time we ran the NDepend for this project. For understood the metrics in dashboard, see this reference.
Note: Code Coverage by Tests is empty because is needed to import this information. NDepend can import coverage data from:
- NCover™ 3.x and above coverage files
- Visual Studio™ 2013, 2012, 2010 and 2008 XML coverage files
- JetBrains DotCover™ 1.1 and above XML coverage files (with special NDepend formatting)
Code Rules section has some violations, rules that are ok 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
http://s2.postimg.org/f3k2ps01l/ndepend10.png
The rule violated is "Avoid having different types with same name" and we can click in the "Avoid having different types with same name" for see more details.
And in the right windows we will see that. There are two classes that has repeated name, see it in solution explorer
http://s27.postimg.org/mdegfkilv/ndepend11.png
Is true, is used the same name in different dlls, but these dlls will never use together and the NDepend should be smart enough for understand these types are not used in the same context. Is possible to see the query used to verify this rule
http://s28.postimg.org/46l4opqyl/ndepend12.png
The question in this moment is can I change this query to support this specific case?
Yes, we can change the query used and should create the query for support this. Later we will see a simple case where we will change the query. Let's see other violation, for it click in left menu:
http://s30.postimg.org/87r6xdtbl/ndepend4.png
Is possible to filter for see, for example, the Rules Violated, here is the list
http://s11.postimg.org/oghy37nj7/ndepend14.png
There are rules that should be fixed, for example:
- Methods too big
- UI layer shouldn't use directly DAL layer
- UI layer shouldn't use directly DB types
and others... But there are rules that 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 help in that response, and we can change it for that we want!
http://s24.postimg.org/9fr3edemd/ndepend15.png
With it, is very simple to change the rules for that we want! There are more queries that need to be changed, another example is
- Class with no descendant should be sealed if possible: this is another great rule, but if the model is related with database and is using EF and the properties are virtual, the class cannot be sealed.
See more about change queries rules here and here.
[
NDepend ](http://www.ndepend.com/)generate a Dependency Graph, that is very interesting, Visual Studio Ultimate has this feature too.
Here is the result for this project http://s27.postimg.org/i5ahfc2er/ndepend13.png
This graph should be clean, if it show a lot of connection and looks confuse it means your code has a lot of dependencies and maybe something is not ok. If you are using dependency injection your graph will be clean and beautiful.
*
Note*: This project don´t use DI, but it is a small project for this reason not looks confuse and gives the idea that all is ok. 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 feature here.
For finalize, is important to define all options related with this tool. For example, define when the NDepend report should be done
http://s17.postimg.org/602gzk1r3/ndepend16.png
See more about it in this reference Rules Execution Options.
Conclusion
In conclusion, NDepend is a great tool for measuring the quality of software development for a .Net projects. In this article we only generated twice the reports but for a real project it can be useful for follow the metrics, violated rules... The possibility of editing the queries rules is a plus for this tool.