In my previous post, I introduced NDepend and talked about how to get started. Now I’d like to review why I want to use it on my projects.

First of all, I really like the analysis reports. Not only do they show you instantly the current state of your application and how healthy it is (or not), but it also gives you an objective and systematic way of introspecting your code base. In conjunction with the code query constraints and metrics, they really help you monitor the quality of your .NET components. Even more so if you can run them as part of your build process.

As Mark Needham pointed out in this blog post, remembering to follow some of the OO design principles is not always an easy task when you’re coding. However by having the tool check for adherence to pre-defined rules/best practices, you can automate the identification step of the refactoring process thereby giving the Dev team more time to focus on the overall design, behaviour and functionality of the system.

Visual Studio already includes code analysis and FxCop but NDepend goes a lot further and one of its strength is that it let’s you visualize your code in a way that no other tool does. Napoleon said “un bon croquis vaut mieux qu’un long discours” (which more or less is the same as “a picture is worth a thousand words” in English) and so the diagrams produced by NDepend can help you digest complex architectures more easily.

Now you might also ask what is wrong with just using the built-in Visual Studio 2008 code metrics? Well nothing but NDepend gives you much more than just cyclomatic complexity, depth of inheritance, class coupling and lines of code. There’s more than 80 code metrics out-of-the-box and if one is not applicable or you feel is inadequate for your particular application, you can easily customize the report by amending existing code queries or creating new ones to suit your needs. Also Visual Studio is not as granular and does not let you drill down the dependencies.

Note that NDepend has some rules defined around naming conventions but I think StyleCop is probably better suited to enforce a specific coding style and ensure consistency. Nonetheless NDepend includes some useful additional constraints such as the ones setting limits on the length of method or field names. Moreover it is relatively easier to add your own custom naming conventions for your particular project with NDepend.

What initially sparked my interest in NDepend is that it really complements ReSharper as a refactoring tool. In particular there are a few key design concepts that ReSharper’s code analysis simply does not cover, yet can be evaluated using NDepend: cyclomatic complexity, number of method parameters, class cohesion, total coupling and inheritance depth to name just a few. But with both tools in my arsenal I feel better equipped to write cleaner and more SOLID code.

I probably sound like an NDepend fanboy but I am passionate about using the right tools for delivering quality software. Yet NDepend can still improve in some areas and I have put below a wish list of the things that IMO would help make the tool even better:

• Better integration with Visual Studio as I don’t like to leave my IDE and flip between the two all the time.
• Code duplication analysis to reduce code clutter and abide by the DRY principle. Note that some of my colleagues have used Simian in the past to do this but I would personally prefer to do this with a tool I’m already using and familiar with.
• Full screen mode for graph and dependency matrix windows.
• Easier navigation between views and better shortcut support. There’s no shortcut for example to close an active window or to cycle through open windows (similar to Ctrl + Tab in visual Studio).
• Automatic filtering of test projects when adding assemblies from a Visual Studio solution.
• Being able to delete NDepend projects from the start-up page as at the moment you have to mess around with xml files to do that instead.
• Quick search textbox in the Class Browser window similar to the one found in Visual Studio so that I can quickly go to a known type rather than drill down the treeview.
• Cheaper single user licenses as I think the current pricing model is a barrier to entry for most Developers.

Finally I’d love to see some sort of integration with ReSharper. It would be great to be able to define code queries using NDepend and have ReSharper flag them as solution errors if the constraints are not met. This is probably fiction at the moment but one can dream!

Overall NDepend is a terrific product to pick up. It should save time over the lifecycle of a project, facilitate communication and increase productivity by aiding refactoring and generally making maintenance tasks easier to perform. Did I mention that it is also a cool way of learning about code metrics and some fundamental OO design principles?

I haven’t fully grokked NDepend yet but practice makes perfect and I’m really looking forward to use it on my next project. With the upcoming release of Visual Studio 2010, StyleCop + FxCop + ReSharper + NDepend will be a killer combination for developing .NET apps.

Disclaimer: This evaluation of Visual NDepend is based on a copy of the Professional edition supplied by Patrick Smacchia.

Caring about quality is not just about producing great code but it is also about producing great software.