One of the tools I’m using is NDepend (http://www.ndepend.com/). It is a cool application that can be used for a lot of things, as will be detailed later.
To use NDepend you have to feed it with a set of assemblies. After that, it will analyze those assemblies and their reference assemblies. If the PDBs of the assemblies are available it will use them so more data is analyzed, although the PDBs are not needed for NDepend to work.
After the analysis has been completed, NDepend looks like this:
I have used version 1.1 of Spring.NET Framework (http://www.springframework.net/) for the sample. As you can see the application has a beautiful GUI. I’ll talk a bit about the main windows of the tool:
• Metrics: this window gives a graphical high level view of the project. You can see a lot of ellipses and some of them that are made of smaller ellipses. The big ellipses are types of the project. If a big ellipse is made of several smaller ellipses, those smaller ellipses are the methods of the type. The types of the same namespace are distributed in the same rectangular region, separated by a small yellow line. The assemblies are separated by a thicker yellow line.
By watching this window you can get an idea of which assemblies contain more code, which types are big, which types have a lot of methods, etc. The window was in “Method Level”. The available levels are Assembly, Namespace, Type, Method and Field.
• Class Browser: this is where the assemblies of the project and its referenced assemblies are shown. You can expand the assembly up to the field level. While you hover over an item in most windows, the Metrics window gets updated highlighting the hovered item.
What it’s really cool about the Class Browser is that for the referenced assemblies, only the namespaces, types, methods and other items that are used by the project are shown.
• Info: When you hover over an item the information about it is displayed here, with some metrics if applicable. There are a lot of metrics so it can take time to interiorize them and judge their value appropriately.
• Dependencies: this window is a bit intimidating at first but like a lot of things, with a bit of effort you can master it. The window displays very important information of the dependencies in a matrix form. As in other windows, the detail level is selectable, from the assembly level to the field level.
A cell can have 3 colors. Blue means that the associated item in the top header uses the associated item in the left header. Green means that the associated item in the left header is using the associated item in the top header. Black means a cyclic dependency. The blue and green cells express the same dependency using opposite points of view.
You can see a diagram of the dependencies clicking on a cell. For example, if you click in the cell corresponding to System.Web.Extensions and System.Web you get this:
To read more about the theory of dependencies take a look here:
• CQL Queries: CQL stands for Code Query Language and it is a central piece of NDepend. Being able to ask questions about the code is great. If you like using the Analyzer window in Reflector you’ll love this. You can create new queries and modify the existing ones.
I have presented the main NDepend windows, but the main question is: what you can do with NDepend?
There are several uses that I can think of:
• It is an excellent tool to check differences between different builds of an assembly. You can use it as a diff tool, as it will show in the Class Browser which types, methods, etc have been added, removed or changed. This information is also available for CQL Queries, with the power that it implies.
• It can be used to understand code. When you are thrown with code that you have no clue about how it works you have several options to accomplish that task:
- Look at the source code directly.
- Make some diagrams from the source code (for example, using View Class Diagram in Visual Studio).
- Use NDepend.
These methods are not exclusive, and probably you’ll use a combination of them to understand how the code works. However, the abstraction level is higher when you use NDepend is higher than when you use a Class Diagram (and a Class Diagram is a high level view compared to raw source code). I’d use NDepend to have a global vision of the main assemblies, type most used, dependencies between namespaces, more complex methods, etc. and then focus my attention in the most important parts of the application, going to a lower level of detail.
• It can be used in the refactoring process, to see the impact of a change, and to keep dependencies to a minimum, in order to have a project that is easier to understand and maintain.
• Integrating NDepend in the software development process. IMHO this is a key point, as using NDepend regulary will certainly improve the quality of the software that is being developed. NDepend can generate a report of a project. A sample report is available here:
There are a lot of sections in the report, but I’ll concentrate on the section called “CQL Queries and Constraints”. That section is really important as it shows a list of items that can be problematic or don’t follow the standards of your company (methods with a lot of lines of code, very complex methods, poorly commented methods, types or methods or properties or fields with incorrect naming conventions, etc). This way the project leader can make periodic checks of those problems and report them to the people that are responsible for them.
This also allows you to know more the people you’re working with. Some developers don’t comment code, others like to make very long methods, and others tend to write complex logic that is difficult to understand by others. With the review of the report, they can be instructed so the resulting code and comments is better and more uniform.
However, there are times where a method with more than 30 lines of code is necessary. Or a method with a cyclomatic complexity of 25 is needed. So it is up to the project leader to review the suspicious method and inform the developers of the problem or simply acknowledge that it is necessary.
Unfortunately, NDepend does not provide built in support for this level of detail of project management. I have been told that in a future version it will provide hooks so custom scenarios like the exposed above are fully supported.
So, after what I have said about NDepend, you can be thinking, is it for me? Well, that depends on a lot of factors. I know a lot of companies that have no interest in achieving high quality products and that they only care about having a project done as soon as possible. If the maintenance of that project is a nightmare, well, that is another problem for another moment. However, there are some companies that actually spend time and effort to produce excellent products, so they may be interested in what NDepend can add for them.
I have used NDepend in several projects that are widely used when learning about it, and I found something curious:
The image shows that almost all of the NHibernate code has a big dependency cycle. I wish them good luck making the transition to ASTs.
To finish this post, I have to say that I have received a free professional version of NDepend. This has not conditioned my post about it. If I think it was a useless product I will not have posted about it.