As a very long user of Visual Studio and a little less (but still long) user of Jetbrains Resharper, I’ve started to look out for a tools that would fit in my developer toolkit to cover most of the cases I encounter at work. I’ve decided to split them in general groups of my needs and then look out for tools that would help me in working things out.

One of them is decompilation of .dll, that I work with and would love to understand internally. I’ve started to use Resharper built in decompiler, but since I now own Red Gate Developer Bundle including famous Reflector, I choose it over R# in advanced scenarios.
Another one is definitely performance bottlenecks and general memory profiling. That’s were I rely on Red Gate’s product too.

But today’s post is not about those things. There was actually one tool that I really looked for few times already and failed to find. I was looking for a way to analyze my programs for code quality, meeting conventions I enforce and for general static code/program analysis.
I’ve tried few tools already, mostly free and the one that was actually closest to meet my requirements was StyleCop. It did its job, well… ok. But it was counter intuitive, lacking decent summary of analysis. Generally, UX sucked.
However, recently I’ve been contacted by Patrick Smacchia with an offer to try out his tool for general code analysis.
Let’s see then what happens when Visual Studio meets NDepend!

Review spoiler

What you probably expect here is classic functionality review, like in any other product review: we have this, and that, and that.
I chose to go the other way round and think of use cases where this tool actually fits.
My hopes are that it would make a little easier to decide, whether it fits your workflow, or not! 😉

Case I – Annual Code Quality Review

Use case

Team Leader or developer team as a whole wants to review code quality of a currently worked project to ensure it meets their criteria of ‘clean code’.

Proposed way of analysis

Depending on what we want to check, let’s scan our solution assemblies with chosen criterias and visualize everything with a heat map (called in NDepend ‘MetricTreemap’). As general Size rule I will choose # lines of code (LOC).

My proposed criterias are:

• lines of code, per method (Level: Method | Color: # lines of code (LOC))
• number of methods, per type (Level: Type | Color: # Methods)
• Cyclomatic Complexity aka independent paths through source code, per type (Level: Type | Color: Cyclomatic Complexity (CC))
• if API for external exposition percentage comment, per type (Level: Type | Color: Percentage Comment)

What do we get as a result?
As an output for every criteria we’ve chosen, we got a nice, colorful heat map representing places we need to take into consideration for refactoring. Example below of a map of lines of code, per method in a solution (gathered per assembly):

Proposed way of acting

With information we have and tools we mentioned in the beginning of the article, we now can do quite a lot to clean up our code.
Let’s take a too long method code smell that NDepend pointed us out. It will be easy to point out issues as we use a natural way of doing so – the closer to red color, the more serious problem we have.
Now, using power of Resharper to refactor the code, let’s extract a part of logic from too long method into another (possibly private) one:

• Select part of logic you think is suited for extracting
• Right-click -> Refactor -> Extract -> Extract Method…
• Choose suitable name that will easily be recognizable for its responsibilities in a method we are extracting from
• Voila!

If things get really messy, you would have to perhaps think of dividing the job to avoid technical debt. 😇
Please also note, that basic extracting mechanics are also available in Visual Studio (though not so good as in Resharper!).

Case II – Defining crucial, yet external dependencies

Use case

Throughout a lifetime of a project, team (or management, or both) can come up with an idea of switching few parts of current solution to meet new business needs (or pending deals).
Possible case could be migrating from EntityFramework to NHibernate (or other way round, or moving back to plain old SQL) or switching current JSON parsing library or perhaps moving to .NET Core?

Proposed way of analysis

Let’s think of a case when we decided to migrate from EntityFramework to other ORM. Before we even think of how complicated it would be to replace dependency, we would need to analyze how deep that dependency is. In general, first thought would be to check our data access layer and look upon its dependencies.
Let’s give it a shot then and see Dependency Graph that NDepened provides us with, when we right click on our data layer on graph and choose Keep only nodes that I use:

Alright, we can see clearly that there is dependency to Entity Framework up here. But what if our implementation is leaky?
We should probably see if Entity Framework is not referenced by other layers of our solution.

Let’s go back to all assemblies on dependency graph by choosing first icon on the left in DependecyGraph menu: View Assemblies .
Now let’s find again Entity Framework and now choose Keep only nodes that use me.
We should end up with a dependency graph of what is really using our beloved (but to be migrated from) ORM framework:

We now clearly see, that there is one more direct dependency (GatewayApi in this particular case) to the ORM that we want to swap that we need to consider when making decisions on changing technology.

Proposed way of acting

Since we already defined possible points of problems – including ORM leaking out of data access layer – we need to analyze the complexity of code that we would need to rewrite. NDepend could help us here too a little, if we analyze actual complexity of dependency usage with previously used heat maps or change size of nodes in dependency graph to visualize how many calls to particular dependency we have.
This is of course where NDepend will end up being useful, as out of analysis stage we actually need to get into code and make decisions.
Great thing is that we already have an insight on the problem and can decide having broader knowledge on how many places can actually go down, when anything (or everything 😇) goes wrong.

Other use cases and verdict

While those two mentioned above were the one that immediately came up into my mind, I can think of few other (yet less probable) cases where Visual Studio toolkit and NDepend marriage would bloom.
We could for example troubleshoot performance issues (but not prematurely!) using RedGate’s performance toolkit for .NET developers and use it along with Cyclomatic Complexity, amount of memory allocated per type and number of IL calls that NDepend can visualize us with Metric Treemap.

Verdict?
Would I recommend using NDepend for analyzing and keeping in bounds projects that we’re working on? Definitely!
Can I see any points of improvement for NDepend? Yes, perhaps. Dependency graph UX needs a little more improvement. I couldn’t find ‘Search…’ option in it too, what made it a nightmare to find smaller node.
But, in the end, I guess it all goes down to the point where we need to share our feedback with Patrick (the creator) to keep the improvements coming.