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.

NDepend is a static code analysis tool that offers some really unique features to help you improve the quality of your .NET applications. It can be used for conducting code reviews, highlighting areas that should be refactored, finding out dependencies and visualizing a complex code base. Ultimately NDepend aims to assist Developers in making more manageable and maintainable software.

NDepend is one of these rare tools I wanted to use for a long time but always found the limitations of the trial version too frustrating to live with. Now that I have a working copy of the professional edition, courtesy of NDepend creator Patrick Smacchia, I have been spending some more time with it, learning how it can help me write clean code along the way.

You only have to google “ndepend” and follow some of the links to find out how well regarded NDepend is within the .NET community. So what surprises me is that its adoption does not seem as wide spread as something like ReSharper, a tool which also aims at increasing code quality and Developer productivity. So why is it that a product with so many rave reviews has not gained the same traction as that of other coding tools out there?

Probably part of the answer lies in the perceived complexity of NDepend. It is indeed an intimidating tool and as soon as you open the start-up screen you are left wondering what to do next. This is not a tool that can be tamed in 10 minutes. It does require a certain amount of time, effort and experimentation to start enjoying its benefits. So where should you start to make that learning curve a little bit more gentle?

The amount of information provided by NDepend can be quite overwhelming at first and therefore a good starting point is to simply generate a report for a small project you’ve been working on. Using a code base that is familiar and relatively simple to follow will help you get a rough idea of the kind of information NDepend can provide without getting too bogged down into all the details. You can follow the steps below to quickly generate a report (I’m using the BlogEngine.NET source code here):

1. First build the Visual Studio solution for the application you want to analyse in debug mode - NDepend uses both the dll and pdb files (for linking back to the source code) to carry out the code analysis.

2. Open NDepend and click on ‘Create Project’ on the Start Page.

3. In the ‘New NDepend Project’ dialog, enter name and location, and OK:

Once the new NDepend project is created, the ‘Project Properties’ window will be displayed.

4. Select the Visual Studio solution you want to analyse:

5. The loaded assemblies should now be displayed:

6. Either press F5 or click on to run the analysis report.

After a few seconds, the report will automatically be displayed in your browser.

Once you’ve ran the report, you can use the VisualNDepend UI to browse your code.

Now you can either spend some time in the UI trying to work out what it all means or, preferably, head straight to the NDepend Web site and watch the online demos. There’s loads of documentation on the site showing you how to navigate the UI and to help you understand the information NDepend generates. Unfortunately the screencasts are not available for off-line viewing but they are however all relatively short (the longest one lasting no more than 5 minutes). After that you will be ready to explore and make sense of your code base armed with your newly found knowledge of code metrics.

There’s a couple of things I’d like to point out at this stage. First the NDepend install does not setup an entry in your start menu or a shortcut on your desktop so you might want to either create a shortcut for it or add it to your app launcher - I’m using Launchy for quickly accessing all my favourite applications. Second, by default the results of the CQL (Code Query Language) queries are evaluated automatically. I personally found this confusing at the beginning and you might want to turn that off to start with. To do that go to Tools > Options and uncheck "Execute automatically the query edited as soon as it compiles" as shown below. Once you’ve gained more confidence with the UI and how CQL works you will probably want to switch that option back on.

Finally, don’t dismiss the Info window took quickly. I initially ignored it without realising how useful it can be. Not only does it display detailed information about assemblies, types and members but it also gives you the description of dependencies in plain English; very convenient when you’re not familiar with the Dependency Matrix.

I won’t go into the details of what NDepend can do as there’s a well documented list of features on the site and other people have already done it better than I could - read NDepend: code metrics at your service for example. For more in-depth coverage of NDepend you can also follow Patrick Smacchia on CodeBetter.