I’ve always been working in enterprise projects. They usually involve tons of code and sophisticated extensive dependencies inside of code base.

On the other hand I’m keen on keeping code as clean and simple as possible. But how do you find problems quickly within huge set of solutions/projects/assemblies when lot of teams work on those? You have no idea who writes good and who writes bad code or where to look for potential bugs or ugly design.

When you have to analyze a lot of code there is no better static analysis tool than NDepend. There are quite a lot of tools which could perform some analysis here and there, but biggest advantage of NDepend is that everything is in one nice package.

Probably the most exciting feature of NDepend is Code Query LINQ. It allows you to write your own customized queries. Want to see all methods that have cyclomatic complexity higher than 5 and with more than 15 lines of code? Not a problem. Just run this:

from m in JustMyCode.Methods where 
  m.NbLinesOfCode > 15 &&
  m.CyclomaticComplexity > 5

select new { m, m.NbLinesOfCode, m.CyclomaticComplexity} 

As easy as that. Double click on a method and you are already editing it in Visual Studio.

I also like that tool provides analysis on different levels of details. On bigger scale you can identify problematic assemblies. For this purpose there are couple of features. One of them is “Abstractness vs. Instability”. It generates great image with distribution of your assemblies.

Image below was generated for one of projects I’m working on. If most of your assemblies fit into green zone than there is a good balance between abstractness vs. instability. I’m proud to say that code which I write always is in “green zone”.

I went through few of our projects and indeed projects with problematic code base is usually close or is in orange zone. It can be considered bad if you are in “Zone of Pain”. Scott Hanselman has nice post on this and NDepend in general called “Exiting The Zone of Pain – Static Analysis with NDepend”. Check it out.

Another high-scale features would be “dependency graph” and “dependency matrix”. While first one is something that comes with VS (well Ultimate), second one is more sophisticated and not found that frequently in other tools.

This feature gives you complex matrix of all dependencies all the way between assemblies. You can expand it to classes and even methods. On the picture above a dependency cycle is shown. What is great about NDepend is that it always explains in plan English why and what is shown. In this particular situation there was cycle dependency because compiler generated help class for linq query, so I ignored it as I cannot do much about it. But you never know, next time you might have a problem with your code.

When you run analysis NDepend would check against built-in code quality queries. What you get is something as below:

When you click on items on the right you get detailed list of matched classes/methods so you can go through them and verify if anything has to be changed. To be honest even that I’m very scrupulous when it comes to code quality, I discover a lot of new things for myself.

For example I got this in section “.NET Framework Usage”: Collection properties should be read only with an explanation from MSDN:

// A writable collection property allows a user to replace the collection with

// a completely different collection. A read-only property stops the collection

// from being replaced but still allows the individual members to be set.

// If replacing the collection is a goal, the preferred design pattern is to

// include a method to remove all the elements from the collection

// (with a call to the ICollection.Clear() method) and then re-populate the collection.

Of course it makes sense, but I just never thought about it. And there are many-many other things which you can learn from the tool only by using it.

During my working experience I started to think that people tend to create too many projects in VS when they finally feel comfortable with doing so. I like when there are as few assemblies as possible. Folders/namespaces are very good logical separation of code, there is no need in assemblies A, B and C if they always run in same application domain and depend on same stuff. NDepend team advices this and also reasons about it. You can read their “white-books”.

Other cool thing about NDepend is that it can be integrated with Visual Studio and Reflector. When you run NDepend it provides you with start page which proposes these add-ins for you. This is very handy.

It is natural that NDepend has console so you can run it from you scripts.

You can see complete list of NDepend features here: http://www.ndepend.com/Features.aspx

I’m afraid that my thoughts were somehow not well structured, I just picked some of the capabilities NDepend has and did not talk much about different use cases, but don’t worry. You will find answers to all your questions on web site: www.ndepend.com/

In my current company NDepend is integrated in build process, in my previous company I used it occasionally to see how we progress over time. Big companies usually take code quality seriously as smallest design flaws now could mean a lot of money leaks in future. Of course everything boils down to employees, but if they have right tools at their disposal you are protecting yourself. This great tool has a price that for sure doesn’t break the bank especially for company that claims to ship high quality software.