The other day I got an email from Patrick Smacchia, generously offering me an NDepend licence on the grounds that if I find it useful I can write about it on my blog. NDepend allows you to write Linq queries against an assembly or a code base to interrogate it for quality issues and see various metrics and reports. I have a personal project underway which I’ve been working on for some time, so I figured I’d give it a go and see what it can tell me. I’ve gone through one ‘round’ of changes from its initial report, so I’m going to write a series of blogs covering them - this is the first.

My project is an object-object mapper (y’know, like AutoMapper) which can deep clone, merge and update objects, as well as telling you up-front how it will do any of those operations for a pair of types. It’s my second attempt and I’ve been working on it on and off for about 7 months. It has one project for the mapper, and one for tests. I’m using ReSharper 8 which tends to stop me from doing anything too silly, so I was interested to see what NDepend would pick up.

After installing it into Visual Studio 2013 I ran an analysis and was presented with the NDepend Dashboard for my project:

…the first thing I noticed of course, was that I have 4 Critical Rules Violated - which sounded to me like A Bad Thing - but looking over the rest of the report there’s lots of other useful info. There’d be even more if I had test coverage data I could feed into it, but I don’t have that right now, so I’ll check that out at a later date.

Ok, let me see what Critical Rules I’ve violated

So, I’ve got circular dependencies between namespaces, 40 methods which look like they aren’t called, an abstract class with a non-protected constructor and an Exception type which doesn’t end with the word ‘Exception’. I decided to check out the abstract class first because I thought ReSharper would have let me know I had one of those, like this:

This is what NDepend showed me when I clicked the abstract class constructor rule:

This is how all rule violations are reported - at the top you have an explanation of the rule and the Linq query used to run it, and at the bottom you have the results. It’s picked up the Member class, which is the base class for a series of classes which represent fields, properties or methods on a Type. Let’s take a look…

Well how about that - yep, it’s an abstract class with an internal constructor. Turns out ReSharper doesn’t mind if the constructor is internal. So I fixed that and moved onto the dead methods, which I’ll write about next time.