How complex is my code? Ask NDepend!

Analysis of source code has become quite a “business” topic in the last few years. Due to that a lot of software tools have been released to help the developer to analyse the source code. In the Delphi World there is the well-known product called Code Healer by Sock Software (http://www.socksoftware.com/codehealer.php). However, a product called NDepend has come to my attention which offers a way to really dive into your code!

You can use NDepend in association with many products. There is an IDE integration for Visual Studio and Lutz Röder’s Refelctor available, for example, but you can also start a seperate GUI that allows you to select the source you want to analyse. An analysis consists of two things: For one, a huge easily navigable report in html format will be generated. Furthermore, and this came as a surprise to me, as an earlier version of NDepend did not offer this tool, the GUI has been extended so that you can query and browse the results. This is actually what makes this tool so useful. We all have heard the principle of creating “loose couplings” between separate source code groups. E.g. you should encapsulate persistence, user interface and business logic seperately. Can a tool like NDepend help me to verify that I succeeded in doing so? You might have guessed that this is a rethorical question…so…yes.

Thus, I do not want to list all the fancy features that NDepend offers you (you can simply look them up here: http://www.ndepend.com/Features.aspx), instead I want to offer an example why NDepend is something I do not want to miss anymore while developing applications.

So, let’s get started with the example.

People, who attend my sessions about ECO, will always hear: ECO will take care that you get a great basis for encapsulating your code properly. Fine. But does it really? Did I do something while writing my application that defies this princriple?

To verify this statement, I started the NDepend Graphical User Interface (aka VisualNDepend.exe) and selected the assemblies my application consisted of. Be aware, if you analyse an application that is built upon a framework, you should include the framework assemblies as well. After selecting my assemblies, I generated a report (it’s a click of a button) and directed my attention to the dependency matrix. Sounds geeky and complicated,  but it is not. Every row and column are labeled with the name of  a namespace. The numbers in the cells designate the number of types, members  etc. (you can actually select that in a combo box) used by the other namespace. So, looking at the screenshot below, we want information about the number of types used in the different namespaces.

Interestingly, we can clearly see that any persistence operation is only being dealt with in the Eco Space as the Eco Space embodies the Persistence Mapper and the Data Connection Components. How can we see that? Look at the namespaces Eco.Persistence and its sub-namespaces. Any type from that namespace is only used by the EcoSpace namespace, but not by the business model, which is in the namespace marked with “.Model”. Same applies to any class from the System.Data namespace, which includes all the database-related classes in .NET. On the other hand, System.Windows.Forms, which contains all the GUI classes, is not being used by the EcoSpace or the business model. Thus, my encapsulation is perfect in this example and NDepend made it really easy to verify.

As the matrix is a tree you can  drill down in any of the namespaces and get detailed information. You can also double click on any of the numbers in order to get a graphical representation in a state-machine-like fashion that allows you to quickly get a clear view on the structurre of your code.

This is just one brief example how NDepend can really make your life easier. If I encounter another useful result that also proves my points about what I say about ECO in my sessions (*ironical grin*), I will post it here asap.