wagnerblog.com

NDepend is a unique code analysis tool. I believe that currently there is not one other product on the market that can can match its capabilities. 

If you are anything like me, you hate having to read other peoples code. OK, maybe hate is putting it strongly. In as much as you have to get into another persons head and try to understand their design and thought process, becoming thoroughly familiar with someone else’s assemblies tends to be a bit of a chore. Agreed?

During the past six weeks I was asked to review two different projects done by two very different teams, in order to provide some architectural guidance and feedback. So when I tell you that NDepend is very helpful, I speak from actual practical experience.  In both cases NDepend 2.0 clued me in to problem areas that I would not have found on my own without expending considerable effort and time. Don’t get me wrong, a tool like this should not take the place of your discerning eye. Instead it should -and does so admirably - act like a sieve that runs through a codebase and provides pointers and feedback.

Typically I’ve used NDepend in two different ways. First and foremost,  I really like the comprehensive summary of findings to get a feel for the “lay of the land”. This report is usually my starting point. It highlights a number of interesting statistics, along with links to their explanation. For example uncommented code versus commented code, methods with too many parameters and various types of coupling. 

As useful as the summary report is, I found the drill down capabilities of NDepend absolutely staggering in its depth and capability.

Once an analysis run has been completed, you can drill into any assembly and gain useful information at the level of namespace or class or method. I’m sure I am leaving something out here. Nonetheless, the point being that NDepend can be of invaluable service if you have to consider refactoring code that was written by someone else.

During my two code reviews, it helped me to quickly provide feedback to my customer, that outlined areas of concern and the potential impact of refactoring them.

And just in case one of the many, many built in metrics and analysis points do not cover your needs, Patrick Smaccia (NDepends author), has had the foresight to include a way to query the information accumulated in an analysis. He calls it CQL - Code Query Language.  With CQL you can write statements like this - very similar to SQL 

SELECT METHODS FROM ASSEMBLIES “System” WHERE IsAbstract

SELECT TYPES OUT OF NAMESPACES “System.Windows.Forms” WHERE IsUsing “System.Windows.Forms.Control”

If needed, NDepend can be integrated into the build process, similar to the way one might run FXCop. If you have to supervise the code production of a team, then having NDepend flag potential problems for you after a build give you the ability to react faster and address the area of concern before it is forgotten or overlooked.

One of the aspects I especially found useful was NDepends ability to display a nice code diagram in its summary report. This visual aid helped me to quickly find my way around. The sample picture here was taken from an unrelated project.

There is truly a lot of information coming at you when viewing the results of an analysis in Visual NDepend. It took me some time to make sense of this almost overload, but once I got the idea I was very much like the proverbial kid in the candy store.

Click to enlarge.