NDepend: Static Analysis for .NET

Over the past few months, I have been running NDepend on the EventHorizon.Game.Server.Zone codebase to get insight into how my changes affect the codebase over time. I have been really enjoying the metrics I get on the insights of my application, ranging from code coverage and technical debt give me the insights I need to know where I should focus when adding features.

What is NDepend

NDepend is a static analysis tool for your .NET projects written in C#. With NDepend you get insight into your technical debt, including estimates about effort to fix. NDepend includes a wide range of rule sets that give insight into entangled code, dead code, API changes that break prior implementations and points out bad OOP design.

Included with NDepend are integration into Visual Studio, using an extension, and a standalone application that can run next to Visual Studio or Rider, checkout NDepend for more details!

How I use NDepend

I like using NDepend to take snapshots of my progress before and after a feature, with the added benefit of allowing to track my progress over months of development. In the next few sections I will go over a few scenarios I used more frequently with NDepend while working with my codebase.

Code Coverage Monitoring

This article will be structured into the different scenarios I used NDepend to monitor or fix for my EventHorizon Zone Server application. The application is a Game Server deployed as part of a larger Game Development Platform; you can read more details about the platform at Game Development Platform. This application already has a decent amount of code coverage but an equal amount of debt that NDepend helps to identify.

The first scenario will be how I monitor my code coverage, using NDepend, OpenCover and the Fine Code Coverage Visual Studio Extension. Starting with NDepend I can take a snapshot of my current coverage metrics, done locally on my development machine. This will come in handy as I work through a feature and want to keep track of my overall metrics.

The goal is to track our coverage statistics over time, keeping a constant metric over time during the development of new features. Using NDepend to take a baseline snapshot at the start, below is a snapshot in time of the code base before I added Artifact Management and Asset Server integration. Generating a report after Artifact Management and Asset Server integration are completed, we get a delta in the metrics and using NDepend we can get an easy to navigate dashboard.

During the development I like to use the Fine Code Coverage Visual Studio Extension, I use this for quick feedback of code coverage metrics. The extension has a feature that will trigger collection after each test run, displaying hit/miss feedback in the gutter of the editor window. I use NDepend after I commit/build/test the feature to get a new report, this report is show below after the Artifact Management and Asset Server integration features are completed.

Disabling A Rule

In this section I will go over disabling a rule, in my case I wanted to remove the enforcement of the 'Avoid partitioning the code base through many small library Assemblies' rule. The structure of my Game Server is very modular at the assembly or project level, this allows for the game server to be additive in the feature set. Since I wanted to keep the modular structure of the game server, I opted to disabling this rule. Taking note of the Debt in the Dashboard picture above for the Artifact Management feature, 21.31%, we can see how the deleted/disabled rules affect our debt.

To disable a rule, just mark it as inactive in the Queries and Rules Explorer of the NDepend Visual application. Below I have the new Debt metrics, 18.27%, this also gives use a Rating of C. Since this rule was not going to be fixed, by disabling the rule gives more relevant metrics reported.

Disclaimer

I was provided the key for NDepend Developer Edition.