• Using NDepend to find ways to improve an existing code base

    Published by on October 22nd, 2010 1:26 am under NDepend, Visual Studio 2010

    No 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.

    Dependency Matrix

    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.

    image

    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.

    depgraph

    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.

    zoomdepmat

    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:

    image

    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.

    image

    We can access the method directly from the query’s results and update its accessibility.

    image

    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:

    image

    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.

    You can download the NDepend trial (which does have less features than the Pro version) to give it a try. I know I’ll keep using it.

    Tags: ,

Archives

Categories