Using NDepend to find ways to improve an existing code baseNo Comments
The last couple of weeks, while working on a couple of personal projects/samples, I have had the chance to start exploring NDepend’s features. In this blog post, I would like to share some of the features that I believe can prove very useful when developing software using Visual Studio. I will provide an overview, using the WPF Guitar Hero application as the sample solution, of a couple of the features I found most interesting.
NDepend’s Dependency Matrix is a really useful asset, which can be used to quickly determine the complexity of a particular application/library. Unlike a graph, which simply shows the connections between the different components, the matrix displays how dependent a component is on others in a simple way.
To view the Dependency Matrix, after enabling NDepend for the solution, one must simply point to the NDepend menu and click Dependency Matrix.
As the figure above depicts, the matrix shows (in this case) how many dependencies there are between an assembly (column) and each of the other ones (rows). Additionally, it does not only show dependencies to assemblies from within the solution, but to .Net Framework assemblies as well. In this case the unit of measure being displayed is members, but it can also show methods, fields, etc.
From the matrix, there are different ways to dig deeper into each of the dependencies. One I find particularly useful (for low amounts) is using a graph.
If the amount is large, you can also zoom in to the particular assembly pair and get a look at the dependencies one by one.
CQL (Code Query Language)
Another great NDepend feature (my favorite so far) is its support for the Code Query Language. Let’s say that for API clean-up purposes I want to find all methods that can be made private, you might use something like the following:
SELECT METHODS WHERE CouldBePrivate
Which outputs these results:
As you can see there are many methods from assemblies related to Unit Tests. We don’t care about those so we can get rid of them by adding some extra filters to the query:
SELECT METHODS FROM ASSEMBLIES “AlgoHero.Files”,“AlgoHero.Game”,“AlgoHero.Interface”,“AlgoHero.MusicEntities” ,“AlgoHero.Screens”WHERE CouldBePrivate AND ! IsConstructor
We get the desired output which does not include any method from test assemblies. The fact that this query returned 12 results means that some methods have a higher level of exposure than required.
We can access the method directly from the query’s results and update its accessibility.
The best thing about this, is that this query can be added as a CQL rule so every time the solution is built the query will verify this condition:
I believe this level of customization, which can be achieved through some really simple syntax can provide great value to maintain large code bases across development teams with many developers compliant with a set of rules.