NDepend Review

I was offered a free license for NDepend in order to give it a try and write about my experience of using it. Because I enjoy writing good, high quality code I jumped at the opportunity. This review covers my first experience with NDepend as I install and test it on one of my open source projects.

What is NDepend?

NDepend is a static analyzer that gives feedback on code quality based on a variety of rules. It works similar to tools like SonarQube or CodeFactor however what makes NDepend unique is its Visual Studio plugin that is capable of providing feedback much more rapidly than a tool that only provides feedback once the code has been checked in and built on a build server. This allows developers to fix code smells quickly as feedback is provided while the code is being written rather than only receiving feedback on code smells after the code has already been checked in.

Installation experience

The product's license key is provided via an email. The mail contains detailed instructions on how to download, install and activate the tool. The download is a small (for my version 15.9MB) zip file. What I found weird (but not displeasing) is that the zip does not contain an installer but rather the tool's executable files itself. You simply copy these files to a convenient locations and it is ready to use. What I found pleasantly surprising is that you can run NDepend as a standalone product or as a plugin directly in Visual Studio (which is definitely the way to go). Installing NDepend into Visual Studio is a straightforward process, you simply execute the extension installer and choose which editions of Visual Studio you want to install the plugins for.

It is also possible to install NDepend on your build server (and the license I was provided does cater for this) however I will cover that in a different blog post at a later date.

Licensing note

NDepends is licensed per seat, meaning that each license allows installation on a single machine only. This is not a major issue as developers usually work on the same machine however in cases like mine where I often travel and have more than one machine this is a bit of a drawback as I will need a license for each machine rather than having the product licensed to me as an individual with installation allowed on all machines that I use.

NDepend does have a convenient online method to track and manage your licenses though, so it is easy to revoke and move licenses when required.

Project Analysis

To give NDepend a proper test I decided to use it on one of my open source projects VaraniumSharp. Currently VaraniumSharp is monitored by CodeFactor and it has a pretty clean record:
I decided that this would be a good project to use for writing this post as it is open source and it already has a good track record.

First run

After installing NDepend a new menu item becomes available in Visual Studio. This menu provides access to NDepend's functionality. While NDepend can be used to simply analyze a project it's true value lies in being able to analyze a project over time. To do this you need to attach an NDepend project to a Visual Studio solution. When adding a solution it is easy to exclude certain projects from analysis (like unit tests projects)

Once the first analysis is done the NDepend dashboard can be accessed to see details about the projects that were analyzed. The dashboard is pleasant to look at and highly interactive giving a lot of details about the project that was just analyzed. It also turned up some issues which suprised me (but will prove useful for this post)

Digging into issues

Digging into the issues is pretty straightforward, you can simply click on the value you want to analyze and NDepend will pop up a window with the details about the issue. In this case, let's dig into the critical rule that is being violated.

The first screen we get to shows us all critical rule failures as well as an analysis of the details surrounding the failure. For now we'll ignore the details and rather see why the rule fails. By double clicking on the failed rule we get to the next screen which shows us exactly where the rule failed as well as an explanation of the reason for the failure. In this case an analysis of the source quickly shows that the code has the Dispose method, but does not implement IDisposable. Now it is time to dig into the code and see why such an oversight occured, in this case it appears as if the IDisposable interface should be implemented but was forgotten when the interface for the class was created so we simply add the IDisposable interface to the IPackageManager decleration.

Once the issue has been resolve you simply rebuild the project and NDepend will run its analysis on the project again. Looking at the dashboard we will now see that the issue has been resolved.

NDepend and code weaving (or how to create custom rules)

VaraniumSharp makes use of Fody and the PropertyChanged addin to automatically generate the implementation for INotifyPropertyChanged (which saves a lot of boilerplate), however during my exploration of the errors I came across classes with methods that do not exist. A quick look indicated that these issue were being caused by the code weaving being done by Fody and is thus not present in the actual source code that developers will deal with and can safely be ignored. NDepend makes it easy to add additional rules including ones that can be used to ignore code as notmycode. NDepend uses CQLinq to define the rules and this is easy to use to create a rule that will then ignore the code generated by Fody. The rule editor also has IntelliSense so there is no (well, very little) guesswork involved in creating the rules. Below is the rule I wrote to ignore the Fody errors:

// <Name>Ingore code generated by Fody </Name>
notmycode 
from a in Application.Types
where a.FullName == "ProcessedByFody"
|| a.FullName == "<>PropertyChangedEventArgs"
select a
//<Description>
// Ignore code that was generated by Fody weaver
//</Description>

Other interesting things

One of the rules that VaraniumSharp broke is in the naming of the AutomaticContainerRegistration class, which is an abstract class. Upon renaming the class to AutomaticContainerRegistrationBase NDepends raised a critical error for breaking the publicly exposed types. This will greatly assist in making sure that the exposed public API does not change accidently or in cases where it needs to be changed, that appropriate versioning can be used so consumers know what to look out for.

Code coverage

NDepend also support pulling in test coverage details from multiple test frameworks (NCover, JetBrains DotCover an Visual Studio Coverage). This requires that you generate coverage files using one of these frameworks that it can then access. During development I use DotCover inside Visual Studio to handle code coverage which allows you to save the results to a file.

Overall impression and recommendation

Personally I find NDepend to be a great tool. It was easy to install and is fairly easy to use.
It is fast (even on large projects) and it gives you valuable insight into code issues that I have not found in other tools. It does have a slightly intimidating number of menus and options, however using the base functionality is straightforward. I can see myself using it to assist me in keeping my existing projects (both open source and proprietory) clean and is a tool I would recommend to my company in order to do the same.

So the main question is, do I (personally or as a company) need NDepend? In this regard my answer is yes (with a minor caveat). If you care about delivering good, high quality code NDepend is an excellent tool to get you there. The rapid access to code issues (while you are still writing it) is invaluable as issues can be fixed long before the code hits your repository. For a dev house the answer is pretty clear cut, however if you are a hobbyist/open source developer I find it a little harder to say yes. NDepend is not cheap for an individual (at least not where I live) and the fact that you cannot use it on multiple machines is a little limiting however few dev tools are cheap so if code quality is your thing (as it is mine) it is not that hard of a choice to make.