I was excited in June last year about C# MVP Patrick Smacchia’s static code analyser NDepend and you can read about that here. NDepend has a new release and in this blog I’ll highlight the features that interest me the most, like support for .NET Core. But before we start off with that, first let’s have a look at the integration with Visual Studio 2017, which is important now for writing ASP.NET Core 1.0 web apps.
Support for Visual Studio 2017
Just follow these instructions and you can add NDepend as an extension to Visual Studio 2017! Once installed, as per the aforementioned link, your extensions and updates window looks like:
The NDepend extension is circled in red. You’ll have the familiar menu items available to you:
But of course as expected with a new release a whole slew of new options as well, as the VSTS Integration menu item circled in red, which I’ll get back to in a separate paragraph. This paragraph is about the integration with Visual Studio 2017, which is improved even further with this release by giving more options on when and how to analyse the code:
You can refresh NDepend’s results automatically by starting NDepend’s analysis after each successful built. But this option wasn’t very useful, as it got in the way. With this release you can prevent this behavior when building for a run/debug or unit-test session. Now you can safely integrate it in your feedback loop without it interfering! Plus the refresh interval is now more finely grained to minutes, which compliments to new options greatly.
After it’s integrated in Visual Studio 2017 you can let NDepend go on .NET Core projects!
Support for .NET Core
I am very passionate about .NET Core and that is why the support by NDepend for .NET Core deserves a paragraph on my watch! One of the things that needed to be solved is the ability to target multiple frameworks with a .NET Core project. As you know because of this the output directories will look for instance like: “.\bin\debug\net451”, and: “.\bin\debug\netcoreapp1.0”. These output directories can be resolved now properly.
Project.json will not be supported by NDepend, but why would you want that? If you haven’t already you should really migrate your .NET Core apps to the new .csproj files and use Visual Studio 2017 to develop these projects. NDepend 2017.1 will be able to analyze the .NET Core assemblies and PDB and source files that belong to the assemblies by default. Haven said that, you can always of course simply analyze assemblies in folders if you have a project.json project that you really want to have analysed.
And when you let Visual Studio Team Services build your projects on a build server you can now also use NDepend to guard the quality of your code!
Support for Team Services
NDepend now has an extension in the marketplace which you can use as a task in your build process. It analyses the code using all the same rules you are accustomed to and makes the metrics available to you via NDepend’s hub. So you’ll have the familiar dashboard on which you can see the brand new metrics for technical debt and the passes and fails of the brand new quality gates. Both will be handled in separate paragraphs.
Once installed (or downloaded in the case of using TFS) you can guard metrics like the brand new technical debt, which we’ll discuss now.
Smart Technical Debt Estimation
First of all, what is technical debt? A quote from Martin Fowler:
“In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”
And don’t forget Ward Cunningham’s (coined the phrase) YouTube video: https://www.youtube.com/watch?v=pqeJFYwnkjE.
I’m excited about the addition of the smart technical debt estimation as it allows you to show management with clear and concise graphs what the result would be in money on the long run if the team cuts corners here and doesn’t invest time in the architecture there. Management doesn’t speak code, they speak money. For you to succeed as a software engineer it’s important to understand this.
How does NDepend express technical debt is clear from their docs: “The technical-debt is the estimated man-time that would take to fix the issue.” And man-time can be translated to… Money! NDepend expresses technical debt through a set of default rules which are again simply written in LINQ queries. So again very easy to customize to your own needs, or created from scratch. Let’s see how they’ve implemented this by going to the queries and rules explorer:
Red encircled is the addition of “Debt” to the Project Rules category. Here you can see a number of metrics to aid in determining the estimated technical debt, like for instance: “Percentage Debt (Metric)”:
As you can see in the Queries and Rules editor you have more metrics to your disposal, like the estimated total time to develop te code base and the estimated total time to fix all issues. Which can be influenced by the new settings found at the new Issue and Debt tab of the NDepend Project Properties:
You can for instance change the “Average cost of man-hour of development” if this is different in your organisation to estimate the debt better. Now after adding more code to the solution and rerunning the analysis I can see in the dashboard what the effect is on the debt:
Apparently I’ve built up my technical debt, because it went from 11,8% to 19,65% and my rating has gone up from B to C, which means in man-hours I went up from 2 hours to 4 hours and 44 minutes. Obviously this is by estimation, but it can give you an idea. Also to get a more accurate look I’d need to import coverage data of my automated tests.
And you can even enforce the reduction of technical debt if it gets too big with the new quality gates!
With Quality Gates you can enforce code quality rules by disallowing commits to source control if certain metrics get too high or low. These are again LINQ queries which you can adjust or create. The biggest selling point of NDepend in my opinion, as I’ve written about before. So if again you go to the Queries and Rules Explorer:
And you look up the Quality Gates category (encircled in red), we have 14 default queries. We’ll have a quick look at a familiar one, named Percentage Debt (encircled in red). Notice the absence of “(Metric)” which was included to avoid naming collisions. Let’s have a look at the Queries and Rules editor:
It looks almost the same as the new metric we discussed earlier, but please notice the “failif” and “warnif” which makes it a Quality Gate with which you can enforce rules. As it says in the description this Quality Gate will fail if the estimated debt is more than 30%. So in this case when the technical debt is over 30% the built will effectively fail.
I like NDepend’s 2017 release and I’ve highlighted the new features that stuck out to me the most. Visual Studio 2017 has more static code analysis built in than it’s predecessors though, but still not on par with what NDepend offers.