Thursday, 22 August 2013

Improving code quality by using NDepend

Over the past few years I’ve been using many of the tools included with Visual Studio to analyse my code. This has included running code metrics, examining test coverage, and undertaking performance analysis. However, for my money the tools that are baked into Visual Studio don’t really go far enough. While they are continuously improving there are also quite a few gaps in the data they’ll provide to you, and it’s not always a trivial task to translate that data into improved code quality. Enter NDepend.

NDepend is a static analysis tool designed to improve code quality by using code metrics and enforcing a series of rules. It can be used as a stand alone tool, integrates with Visual Studio, and also can integrate with your build process so that you can be regularly advised of the NDepend analysis results. There are all kinds of features in the tool including viewing dependency graphs, running code metrics, and running custom queries on your code. For a full list you should see here.

When you run the standalone tool you can create/open an NDepend project, analyse a code base, or compare two versions of a code base. Once you’ve analysed your code base you’re presented with a detailed screen of results.


You can examine a dependency graph and dependency matrix, which both allow you to detect dependency cycles between components (NDepend can also suggest the best way to remove a particular dependency cycle). The metrics view presents a graphical view of your chosen metric applied to your chosen level (field, method, type, namespace, assembly). NDepend includes a whole series of code metrics, related to code organization, structure, quality, and coverage, which you can use to improve your code quality.

However, the most useful and powerful feature to me is CQLinq which gives you the ability to query your code using LINQ-style queries. For example, you can run CQLinq queries to check:

  • The classes that implement a particular interface.
  • Which methods could have a more restricted visibility.
  • Which methods are not covered by unit tests.
  • That overrides of Method() call base.Method().
  • Whether the UI layer directly uses specific types.
  • Whether your objects are immutable and pure.

NDepend comes with 200 queries, spread over 18 categories including code quality, design, architecture and layering, dead code, visibility, purity, and naming conventions. You can use all the existing queries as is, or adapt them for your own needs. You can also write new CQLinq queries to check/enforce your own criteria. When you select a query category you are presented with a list of queries contained within the category.


When you select a particular query it immediately executes, displaying the results in a docked window. The code for the query is also shown, enabling you to customise it as required. For instance, when the “Methods that could have a lower visibility” query is executed, you are presented with a list of potentially offending methods, their current visibility, and a suggested lower visibility. Selecting the offending method opens it in Visual Studio where you can change its visibility. This is a very efficient way of performing such a task in comparison to scrutinising visibilities manually.

There’s all kinds of other features available in NDepend, far too many to list here in fact. So if you are in need of a static analysis tool it’s well worth taking a look at it. It’s easy to use, the CQLinq feature makes it very powerful, and it goes a lot further than any of the tools included with Visual Studio. Check it out!

No comments:

Post a Comment