I’ve recently begun evaluating NDepend 5.4.1. During the installation process, I’ll admit I was a little underwhelmed. After the Visual Studio plugin loaded, I became overwhelmed. After digging into the many features, I don’t know how or why teams operate without such tools. Let me explain…
Installation
The installation process for NDepend is somewhat unconventional. You’ll receive a zip file containing installation pieces. In the Professional version, you’ll see a few “installable” files and some folders.
Here’s why I was underwhelmed. Firstly, there’s no installer for a ‘suite’ of tools. It’s relatively simple to create a Windows installer using WiX, which would allow for a more user friendly process. An .msi (or .exe) installer would allow for the NDepend.Console.exe, VisualNDepend.exe, and NDepend.PowerTools.exe to have shortcuts easily accessible from the Windows start menu (if you’re unfortunate enough to have been suckered into Windows 8, install Classic Start Menu).
An installer would also put the documentation in a conventional spot, like C:\Program Files\NDepend\docs.
When you install the professional version of NDepend, you’ll need to copy NDependProLicense.xml into the same directory as VisualNDepend.exe. Another reason I was underwhelmed is because many tools these days will sync a license with a remote server or allow the user to copy and paste a license from an email directly into the application.
Years ago, I had installed the trial version of NDepend. I seem to recall the process being a lot simpler, and that’s probably because I downloaded only the Visual Studio add-in.
Honestly, the install process is the only time I felt like NDepend was lacking. It’s a one-time process, so it’s definitely not a deal breaker. When the add-in loaded in Visual Studio for the first time, I was a little overwhelmed.
Features
To say NDepend is feature rich may actually be an understatement. As a software engineer with nearly 7 years of professional experience and roughly 20 years of total enthusiast programming experience, I was shocked by how much was available in the product. That’s not to say NDepend is bloated or unusable, as is the case with many applications with ‘a lot to offer’. I think I maybe didn’t consider the wealth of insight you can gain about your code through static code analysis. The software offers a lot of tools and the website contains a wealth of documentation.
Metrics
I figured the best way to familiarize myself with NDepend was to clone one of .NET’s newly open sourced projects, corefx, and hit it with NDepend. I loaded System.Xml.XPath.XDocument.sln, built it, and created a new NDepend project on the outputs. One of the only problems I really found with NDepend is when creating a new NDepend project: loading outputs from a Visual Studio project doesn’t seem to properly pick up a relative OutDir path for a project like corefx.
On most of my teams during my professional career, we were only considered about a few metrics (fxcop or stylecop numbers, code coverage, number of tests). I had seen metrics maps of code like Facebook’s pfff, but I had never personally used such a tool.
The metrics graph displays type information using a TreeMap. Namespaces with more types or members are displayed as larger boxes, while type information with fewer members are relatively smaller. You can easily filter what gets displayed in this view (namespaces, methods, etc.), and double-clicking any member will take you to that bit of code.
Other useful metrics include: method size, complexity, coupling, method popularity. The dependency graph gives quick insight into your code’s relationships.
Code Rules
Possibly the coolest feature of NDepend is the code rules, specifically the query syntax for editing code rules. These code rules are similar to those found in FxCop or the Code Analysis built into VS2013 and higher. NDepend makes it much easier to make adjustments to the default applied rules than either FxCop or Code Analysis. You can easily select/deselect rules, modify the severity of the rule, rename the rule, or even edit the definition of the rule.
The built-in rules are well-documented queries that allow you to reflectively inspect code using a linq-based syntax called CQLinq. To make this feature even cooler, the editor in VisualNDepend offers intellisense for these reflective CQLinq queries. Selecting and editing your rules is ridiculously easy. If you ever used FxCop, you’ll know how much of a pain in the ass custom rules can be. You don’t write code to define code rules in NDepend, you write queries.
Although it’s probably not possible, I wish NDepend would easily pull my pre-existing Code Analysis rules from my solution and convert them to this CQLinq style rule. A better feature would be in somehow syncing NDepend rules with the Code Analysis rules in the solution. These possibilities are definitely not a deal breaker because, again, code rules are generally a one-time setup.
Code Utilities
To be honest, I didn’t check out many of the code utilities. NDepend does offer quite a bit here. You can easily perform code diffs across analysis sessions and perform some fairly advanced code searches.
You can also easily track trends in test coverage. To load test coverage, as far as I could tell from the documentation, you’ll need to export a report from your test run and load this into your NDepend analysis session. If I had a need to track code coverage, I would definitely do this.
Analysis Report
The report that can be generated from an analysis is fantastic. By default, you’ll see all of your graphs, metrics, and code rules on the main page. This report will have a sliding navigation panel containing links to drill down into each section.
You can check out a sample report on NDepend’s site here.
NDepend allows for XSL transformations on the report if you want to generate a customized report. Check out the report documentation for more information.
Why you need it
Agile teams are always trying to improve themselves. Metrics are an important aspect in the improvement process. Metrics aren’t just for developers. Different metrics benefit developers, while others benefit managers, and others still benefit business stakeholders.
Metrics is not for one population, but for three:
- developers: they are concerned with instantaneous static code metrics regarding static analysis of their code (cyclomatic complexity, comments quality, number of lines, …)
- project leaders: they are concerned with daily live code metrics coming from unit test, code coverage, continuous integration testing
- business sponsors (they are always forgotten, but they are the stakeholders, the one paying for the development): they are concerned with weekly global code metrics regarding architectural design, security, dependencies, …
All those metrics can be watched and analyzed by all three populations of course, but each kind is designed to be better used by each specific group.
NDepend offers all of these metrics.
That quote from StackOverflow actually helps to explain why I was a little overwhelmed by the number of metrics that can be generated by NDepend; I was going at the product like a developer. As a developer, I’m really only concerned with code quality and architectural strength. I don’t necessarily care about trends in numbers, only where the code is now and where my team wants that code to be in the future.
From a management perspective, I’d be fully interested in the trends of these numbers. A plateau in code quality or a drop in code comments/coverage may trigger a warning. Does a team member have personal problems affecting performance? Is the team being overworked? Has the quality of requirements changed? From a single report generated daily or even weekly, a manager can get a lot of insight into the team’s productivity.
Pricing
The price tag for NDepend Professional is pretty steep for a single developer. If your company purchases 20+ licenses, the price is around $270. To put this into perspective, this is only slightly more expensive than Resharper.
I think the product could be sold more modularly or offer licensing terms that activate specific features of the product. For instance, I would have no problem buying a personal license of NDepend at $50 if it only supported code rules. That’s saying something considering Visual Studio 2013 CE has Code Analysis built in. If I had any significantly sized .NET projects outside of my full time job, I could see myself buying a personal license for about $150-200 USD. I don’t think I could bring myself to shelling out $300+ for my own license unless I had my own business (although, NDepend is totally worth it). Consider the quote from StackOverflow above– NDepend provides metrics for three groups within a company structure. Individual developers may find the price tag a little steep.
Conclusion
NDepend has a surprising list of features. I loved the CQLinq functionality of the code rules, and I wish that part of the code was open sourced.
I would definitely recommend NDepend to developers and managers who want to gain better insight into their code over time.
There are a lot more features to NDepend that I didn’t even cover here (power tools, console, build integration, etc.).
You should download NDepend and use it for the 14-day free trial and find for yourself that it’s an indispensable tool for your team.