In my last post, I discussed installing NDepend and getting your first report out, this post is about that report.
I’m not intending to go into every single aspect of the report as it contains a huge amount of information and the report itself provides help and assistance on nearly everything that it contains by linking to resources on the NDepend website.
Note: All details discussed are in relation to the Professional edition of NDepend, it is possible you will not see all this functionality if you are only using the trial edition.
As I mentioned at the end of the last post with the Visual Studio AddIn in place when you build your application, NDepend will automatically kick in, analyze the code and create a report for you detailing metrics, adherence to some standard developer rules, graphs displaying further information about the code base in different formats, etc. Your browser will be launched and the HTML based report will be displayed but this isn’t a simple static report as it provides the ability to drill down into various sections to look at the analysis data in more detail.
The standard NDepend report contains the following sections:
- Summary – application name, report date, etc.
- Diagrams – dependency, treemap, etc.
- Application Metrics – LoC, no. of classes, etc.
CQL Rules Summary – Code Query Language rules that the application has broken
In addition to these sections, you also have a menu that provides access to further information about your code including an easy way to navigate the CQL Rules, I’ll go into more depth on CQL in a bit.
This section contains pretty standard stuff such as the date the report was generated, version of NDepend used, and other information about the report rather than the code. You will also find it contains links to resources specifically for beginners to help understand the report, quick tips (which seems to basically tell you to use Visual NDepend) and a link to the NDepend website.
When running the report interactively, I tend to doubt if this section adds a lot of value as you most likely know everything that it mentions, however, where this section comes into its own is when you generate the report from a CI server and this then allows you to track information about the report making it easier to link report to build and refer back to it at a later date.
The diagrams that are included in the report are images which help you to visualize different aspects of the code base such as its dependencies, how abstract it is, etc. but that is as far as it goes as the diagrams don’t offer any type of drill down functionality.
The metrics contained in this section are things such as Lines of Code, number of methods, number of classes, etc. all fairly basic metrics and again if you are running it interactively may not be of much interest to you but when you have it generated from a CI build, you can look back over reports and track how a codebase has evolved over time.
CQL Rules Summary
Code Query Language is unique to NDepend, it is a DSL that allows you to query your code in a similar way that you can write SQL to query databases. The report comes with many predefined rules that are executed against your codebase and with a simple green, yellow and red indicates the number of rules you’ve passed, violated or have violated a critical rule.
A quick aside a critical rule is a normal CQL query that you have marked specifically as critical and when integrated into a CI server will cause the build to break if it is violated.
For me, this is the most useful section as it lists all of the rules that you have violated and provides links which take you to details of the rule, the CQL executed and a list of the items that violate the rule, be it fields, methods, classes or assemblies.
On the left hand side of the report, you will also find a menu that allows you to quickly jump to various pieces of information, some of which cannot be accessed elsewhere on the report, e.g., Dead Code.
For me, one of the nicest things in the menu is a way to move through the various groups of rules and being quickly able to see the number of rules passed/violated in each group and to be able to drill down to any sub/child rules contained within the group.
When you first run NDepend and see the report, it offers help for the beginner and it looks fantastic so you delve into it, however, once you’ve been using NDepend for a while as a single user, the report doesn’t offer anywhere near the level of functionality that Visual NDepend or the Visual Studio AddIn provides and I can see the report being largely ignored.
As I mentioned a couple of times where I believe the report is of real use is when it is generated from a CI server and provides a really good way to track how a code base evolves over time, as well as ensuring that the quality of the code base meets defined rules. I’m not intending to cover how to integrate NDepend with your CI Server as the NDepend website has really good details on how to do it here.
So you can see what a report looks like. I’ve created a report based on my ADO.NET DAL and you can download the files from here, then all you have to do is unzip to a folder and open the NDependReport.html.
In my next post, I’m now going to look at Visual NDepend and go through the functionality that it provides.