.NET Junkie

As a freelancer I participate in several projects each year. Their size, quality, and size differ quite a lot, but a few times a year I feel the urge of using NDepend on those projects. It helps me understand code bases from an architectural point of view. While it is useful for a lot of stuff, I mainly use it to analyze and visualize the dependencies between assemblies, namespaces, classes, and get an overall picture of how a project is designed or to figure out what the desired design should be. More than once, code has been written without any architectural vision, and when there was such a vision, there hardly ever is any documentation of it and the developers don't stick to this vision.

One area where NDepend can really shine is validating a code base on a prescribed architecture. While I must admit I've never been in the opportunity to integrate NDepend in a build process, NDepend is the tool that you run next to FxCop (code analysis), StyleCop (source analysis), and NCover on your build server. In the past I've written automated architectural tests that for instance validate that LinqDataSource and SqlDataSource controls aren't used in a ASP.NET web application. Those tests used reflection to analyze all private fields of classes inheriting from System.Web.Page. While writing such tests was doable, NDepend not only makes this a lot easier, there are a lot of architectural rules that are simply impossible to test using reflection. You might for instance forbid the use of DateTime.Now (and the like) in your business layer (because you’d rather want to use an interface that abstracts away getting the current time, such as log4net’s IDateTime interface). While you might achieve this by calling the introspection engines Mono.Cecil or Microsoft's CCI in your automated architectural tests, this is quite hellish. You'd be better of using NDepend. Using the NDepend Code Query Language [CQL] such a test would look like this:

    WARN IF Count > 0 IN SELECT METHODS
    WHERE IsDirectlyUsing "System.DateTime.get_Now()"
    OR IsDirectlyUsing "System.DateTime.get_Today()"
    OR IsDirectlyUsing "System.DateTime.get_UtcNow()"

The last few years I've been using the free Trial / Academic Edition for all those projects, which has it short comes. For that reason I was very pleased to get an mail from Patrick Smacchia, the creator of NDepend, who offered me a free personal edition that I can use at home and on-site when I'm working for a client. While he demanded nothing in return, he of course hopes me to blog about this, which -as you can see- I'm doing right now. While of course this 'gift' encouraged me to blog about this, I can honestly say this is one of those tools that saves my day.

Of course there are some things I dislike about NDepend. The biggest annoyance I have with it is this Code Query Language. While the language looks like SQL and the designer uses some sort of IntelliSense, I never really can get the hang of it. I rather see NDepend inject all project metadata into a SQL server database so I can really query it using SQL. I discussed this lately with Patrick and he convinced me this isn't feasible. The problem is however, that the only query languages I know well are Microsoft T-SQL and C# LINQ. CQL is (of course) different (because it's a domain specific language), and while it might not be difficult to work with, I just use NDepend and especially CQL too little to get the hang of it. I wish CQL would work more like LINQ with a clear object model and rich IntelliSense support (vote for more linqishness here). Fortunately, NDepend uses context sensitive menu's that allow you to create common CQL queries. This makes things much more easier.

Another thing that sometimes annoys me is the NDepend UI. The application consists of several parts that can be moved around on the screen or can be docked, much like you can do with Visual Studio. But the docking just doesn't work that great and I sometimes manage to move the parts in such a way that the UI becomes unworkable. I think it is for this reason NDepend contains a 'Reset views' option (CTRL + SHIFT + R). This misbehavior might be caused by the Devexpress docking library that NDepend uses internally, nevertheless I find it a bit annoying. However, I must say after discussing this with Patrick, I wasn't able to reproduce this. But again: 'Reset views' is your friend ;-).

But even with these short comes, for me NDepend is a great tool. I have no doubt that these short comes will be solved in future releases. However, NDepend is not a tool for every developer's toolbox. The tool is especially suited for architects and lead developers that understand the importance of architecture and are working one medium to large code bases. If that's you, and haven't tried NDepend, you should.

The code samples on my weblog are colorized using javascript, but you disabled javascript (for my website) on your browser. If you're interested in viewing the posted code snippets in color, please enable javascript.