NDepend: Product Review

Sometimes you look at a product and think, ?No problem, give me an hour and I?ll have it figured out.?  Sometimes you are right, sometimes you are wrong.  Sometimes it is because the product is just confusing?sometime it is because there is just a lot to go through.  Anyway, I thought that NDepend would be an easy review, I was wrong.  This is NOT because of bad design — I was having trouble because of depth.  There is a lot of depth to NDepend.

A big part of the depth is do to the querying capabilities of NDepend.  NDepend allows you to query your code.  Not just, How many lines of code do I have?  But, which method have more than 30 lines of code?  That query looks like this:

   1: WARN IF 

   2: Count > 0 IN 

   3: SELECT TOP 10 METHODS 

   4: WHERE NbLinesOfCode > 30 

   5: ORDER BY NbLinesOfCode DESC

Not exactly SQL, but a close facsimile there of.

Then there are queries for measuring the number of IL instructions, Method Complexity, Excessive Parameters, local variables, overloads, and even not enough comments (but only for methods with more than 10 lines of code).  Those are some of the default queries.  But the beauty of a queryable interface is that it can be customized.

But wait there is more.  Charts, graphs, visualizations.  This product is tuned to give you a high level idea of what is going on in your code.  How many dependencies does my code have, how much other code is dependent on my code.  Am I too abstract, or not abstract enough (that is a tough one actually).

Speaking about abstractness.  There is one chart that directly charts abstractness, and it is the chart you see to the right.  Please note, that chart was shamelessly stolen from a Scott Hanselman article also on NDepend. 

On the chart are two main areas: Zone of Pain (bottom-left), and Zone of Uselessness (top-right).   In the Zone of Uselessness you have highly abstract code (good) that isn?t being used (bad).  Combine the two and you have very bad.   In the other is the Zone of Pain.  Here there is little abstractness, and the code is being used directly a lot.  In this case any change to your code can cause your application to break.

Near as I can tell, you want most of you code near the middle blue section.  I analyzed most of my code bases and that is where a lot of my code was.  But, as with Scott Hanselman?s code example, I did have some classes in the Zone of Pain.  I think that will happen with most mature code bases.  Don?t fear having some painful code, but you shouldn?t have a lot of it either.  So far I have not found any of my code in the Zone of Uselessness (and I hope to keep it that way).

NDepend figures the values based on Abstractness and Instability.  In NDepend?s language, Instability is the ratio between Efferent coupling and Afferent coupling.  Abstractness is a ratio between the number of abstract types (abstract classes and interfaces) and the number of concrete classes. If that doesn?t tell you that you have some work to do to completely understand this product, then keep browsing the Metrics page.

Just so you know, there are 12 application metrics, 18 assembly metrics, 13 namespace metrics, 22 type metrics, 19 method metrics, and 2 field metrics.  That is going to take time to get your head around.

Summary

With some tools you get out of them what you put into them.  NDepend is like that.  I will say, it is very hard to give an adequate review of a product with so much scope. I see a real usefulness to this product in many cases: you are looking at a code base and wondering A. What was done by those crazy ?other? developers? B. What did I do on this project way back when?  C. How is the product progressing? (Hint: You can compare versions).  I love the way you can browse and drill through assemblies, checking references (the Dependency Graph is great for that).

It is a great product.