Evaluating NDepend on current code base Part 1

A while ago I was asked by one of NDepend's founders to evaluate any .NET code base I wanted with NDepend and write a blog post about it. It turns out I came up with a two-part post. TL; DR Oh boy....
Photo by geralt on Picabay

Enter 3 years old WPF project

Without revealing the nature of the specific project I would just say it is a feature rich client, with UI elements customized to the customer's needs. It is written using MVVM, some third party grids and communicates with an SQL Server database via a classic  DAL class library. All and all the project is comprised of one executable and one DAL assembly.

So off I went and added the necessary assemblies to a new NDepend project and let the analysis run. Given the size of the project it was pretty swift and started off with a a dashboard (or at least this is the view I chose to start from).

NDepend desktop Dashboard

At the same time a very nifty HTML based dashboard popped up in my browser

NDepend HTML Dashboard

The dashboard (as expected from its name) gives one a very good 10000 feet overview of the state of the code base. The first thing that drew my attention on the HTML dashboard was the Abstractness vs Instability graph... Although the Treemap Metric View looks mostly clean (green) the Abstractness vs Instability tells a different story...

NDepend Abstractness vs. Instability

In order to get accustomed to the tool I examined the DAL assembly first. I took a deep breath and set out to see what rules where broken. A little bit of drill down brought me to 14 types and 4 methods in the DAL violating some rule... How hard can that be?

The elusive "Avoid namespaces mutually dependent"

I am not a native English speaker. I do, however, consider myself pretty fluent in the English language and this one I had to run through my head a bit. After reading about it in NDepend's docs, which thoroughly explain how to investigate the issue and acted as per the docs, I got the gist of it. There is a circular dependency between namespaces. One that is not direct or easy to find.

How come the tool finds  a possible circular reference between two namespaces and I do not see it in code unless I am using the tools provided by NDepend? Instead of dismissing the error I took out the good old pen and paper and started writing down the dependencies, inheritances and implementations between two offending namespaces (out of 14 violations). This was more for ducking it out to myself than lack of documentation. When I was done writing down it hit me... Spaghetti code one step away from adding the meatballs. Here is a partial diagram


In one of the cases the solution was pretty simple... Just change the namespace in one interface and the code is untangled. In the DAL assembly however lies the hint for the mess to come. Not all 14 violations where so easy to solve.

More code smells

If you take a close look at the dashboard image there are some more problems there. Some of them denote long types, long methods or long names. Pretty easy to solve. Some of them are warnings that the U.I should neither use DB types nor the DAL directly. I agree on the former. I can argue the latter. And I think that the makers of NDepend where right to make this a warning and not an error.

Ideally the U.I layer would communicate with a service which communicates with the database. Then again ideally none of us likes to inherit other coders code smells; We like to make our own mess...

Some unwanted dependencies

One more thing that I checked out was the overall types dependency graph. I discovered that the DAL has direct access to other domain's APIs as well as direct access to message queues. This may not be a broken rule on the static code analysis but it is bad architecture.

This definitely not good architecture...

Exit DAL part of 3 years old WPF project

"Well..." I thought to myself, "this wasn't so bad. Maybe I will be lucky and the 400 offending types in the actual executable are easy to fix like the first one I checked". Was I right or wrong? On to Part 2.


  1. Despite the fact that the whole project consists of one file, it does not become simple and easy, on the contrary it is even more difficult and problematic for team work.

  2. The post is not about this being in one assembly or many. If I was to write a post about that I would end up writing a 5 part series. Nevertheless some rules can and should be followed even when this is the case. It is obvious that this is not the case here. Rules where broken, if they were in place at all.

  3. I suppose that all work you have done is actually great! You provided a lot of facts and arguments for and against! I am delighted by the description!


Post a Comment

Keep it clean, professional and constructive. Everything else including ethnic or religious references will be removed.

Popular posts from this blog

Tests code coverage in Visual Studio Code with C# and .Net Core

NUnit Console Runner and NLog extension logging for your tests

Applying an internal forums system in the company culture - thoughts