NDepend v4

I was recently given the newest version of the NDepend tool to try out.

Make your .NET Code Beautiful with NDepend

NDepend is a Visual Studio tool for managing complicated .NET code and reaching high code quality. With NDepend you can judge the quality of software using code metrics, visualisations of dependencies on graphs or treemaps, and standard or custom rules - rules that point out overgrown classes, for example.

Once the add-in is installed, all it takes is to create a new project (menu NDepend->NDepend Project->New project) and you can already analyse your code. A small circle appears in the bottom right corner with information about the state of the code; you can look at what ought to be improved, or ignore the rules you choose to.

The newest version adds the ability to write rules in CQLinq (in earlier versions this was CQL, a language close to SQL). All of the standard rules have been converted to CQLinq as well, which makes it easier to write something of your own by example. There is also a great deal of information on the vendor's site.

The rule editor itself has everything you need: intellisense syntax completion and hints about the individual objects available.

An example rule - a warning about singletons:

//<Name>Avoid the Singleton pattern</Name>
warnif count > 0
from t in Application.Types
where !t.IsStatic && !t.IsAbstract && (t.IsClass || t.IsStructure)

// All ctors of a singleton are private
where t.Constructors.Where(ctor => !ctor.IsPrivate).Count() == 0

// A singleton contains one static field of its parent type, to reference the unique instance
let staticFieldInstances = t.StaticFields.WithFieldType(t)
where staticFieldInstances.Count() == 1
select new { t, staticFieldInstance = staticFieldInstances.First() }

// The Singleton pattern consists in syntactically enforcing that a class
// has just one unique instance.
// At first glance, this pattern looks appealing and it is widely used.
// However, we discourage you from using singleton classes because experience
// shows that singletons often result in less testable and less maintainable code.
// More details available in these discussions:
//  http://codebetter.com/patricksmacchia/2011/05/04/back-to-basics-usage-of-static-members/
//  http://adamschepis.com/blog/2011/05/02/im-adam-and-im-a-recovering-singleton-addict/

Every rule not only describes its individual parts, but also ends with a thorough explanation of why the rule matters, together with links to articles that discuss the problem at greater length.

A tool worth a look, especially on larger projects built by a team of people. What I have touched on here is only the tip of what it can do; the best thing is to test it yourself on your own applications.