The Fastest Way to Get to Know NDepend
The fastest way to learn anything is to have simple goals and actions to perform. The same applies to code analysis with NDepend, so let's get straight to work.
Join the DZone community and get the full member experience.Join For Free
I confess to a certain level of avoidance when it comes to tackling something new. If pressed for introspection, I think I do this because I can’t envision a direct path to success. Instead, I see where I am now, the eventual goal, and a big uncertain cloud of stuff in the middle. So I procrastinate by finding other things that need doing.
Sooner or later, however, I need to put this aside and get down to business. For me, this usually means breaking the problem into smaller problems, identifying manageable next actions, and tackling those. Once things become concrete, I can move methodically. (As an aside, this is one of many reasons that I love test driven development — it forces this behavior.)
When dealing with a new product or utility that I have acquired, this generally means carving out a path toward some objective and then executing. For instance, “learn Ruby” as a goal would leave me floundering. But “use Ruby to build a service that extracts data via API X” would result in a series of smaller goals and actions. And I would learn via those goals.
For NDepend, I have a recommendation along these lines. Let’s use the tool to help you visualize your the reality of your codebase better than anyone around you. In doing this, you will get to know NDepend quickly and without feeling overwhelmed.
First things first. Before you can do much of anything with NDepend, you need to set it up to analyze your codebase. You can get here with a pretty simple sequence of steps.
- Download NDepend and unpack it.
- Run the Visual Studio Extension installer and install the extension for your preferred version.
- Launch Visual Studio and open the solution you want to visualize.
- Attach a new NDepend project to your solution, selecting the assemblies you’d like to analyze and then clicking “analyze” (leave the “build report” checkbox checked).
That’s all there is to getting started and running an analysis. I won’t go into more detail here, as NDepend has good online documentation and the nuts and bolts are beyond the scope of what I want to cover, but you’ll find it fairly easy to get going here on your own, and to get your code analyzed.
Once the analysis is complete, you will also have yourself a report of your solution. This will automatically pop up in your default browser window for your inspection. Take an exploratory path through it, seeing what it has to offer. If you’re worried about it being dense or hard to understand, set that aside. The report abstracts away details (until you want them) and presents a nice, visually appealing, and succinct interface.
You’ll see some basic statistics at the top. These include concerns such as the analysis date, the application’s name, the build date, etc. Also up there, you will find links to helpful documentation.
In keeping with the theme of “visualize the reality of your codebase,” the rest of the report’s front page gives you a highly visual representation of vitals about your codebase. You’ll see diagrams of dependencies, metrics, and abstractness/instability and you can drill into those if you like. On top of that, you’ll also notice information about statistics of your application, including rules and metrics.
Don’t worry about understanding every detail just yet. At this point, you just want to make yourself aware of what exists at your fingertips to drill into later.
Next up, I suggest focusing on the dependency graph. If that sounds familiar from the last section, good — you were paying attention. Click on that dependency graph and observe that it lists the assemblies from your application and shows how they depend upon one another.
But that just represents the starting point. If you return from your browser to Visual Studio and select “View Dependency Graph” from the NDepend menu, you’ll see the same graph, but this time with many more options. You can vary the box sizes as a function of different metrics about the assemblies, and you can do the same for edge thickness. You also can control other, more minor options, such as font. And, more macroscopically, you can choose whether or not to see external assemblies and also you can choose to view by namespace instead of assembly.
In short, you can see a nice dependency representation of your application. And you get a great deal of ability to customize what you’re seeing. I can tell you from experience that this form of visualization of your architecture gives you a powerful tool for communicating with technical and non-technical stakeholders alike.
Returning to the report momentarily, check out the metrics view. By default, you will see a view of your assemblies that provides visual information about lines of code (size of the box) and cyclomatic complexity (color of the box). This may seem strange at first, but, believe me, you will become accustomed to looking at code this way.
As you did with the dependency graph, return to Visual Studio and check the Metrics View out there. You have even more levers to pull in your customization of this screen. You can control the level of the metrics (method, type, namespace, assembly), what the size of the boxes mean, what the colors of the boxes mean, and plenty more.
In terms of visualization, you now have at your disposal a powerful tool for getting impressions of your codebase at a glance. You can learn to cycle through metrics, looking for hot spots and problem areas in your code (or, conversely, looking for exemplary parts).
Queries and Rules Explorer
I’ll conclude by mentioning the queries and rules explorer. This may seem an odd choice initially. It does offer a hierarchical view of view of code rules and a visualization of where the code is red, yellow and green (critical, warning, good, respectively). This lets you zoom immediately to problem areas and size them up for yourself.
But the reason I wrap with it is more philosophical. The features I’ve offered as an introduction give you an introduction and a conversation piece. They give you pictures that you can show to help communicate, and to help you understand at a glance.
But the queries and rules explorer gives you the next step in your journey of using NDepend to a deeper understanding of your codebase. Here, you find detailed information about what makes code problematic and why. And here, you find detail about different code properties and how to reason about your code.
As you master this section and learn to tweak and even write your own queries, your mental model of the codebase will evolve significantly. You’ll develop the ability to generate your own, custom data and create visual representations of it yourself, if need be. The queries and rules explorer offers a path to deep understanding of your code.
Published at DZone with permission of , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Knowing and Valuing Apache Kafka’s ISR (In-Sync Replicas)
Alpha Testing Tutorial: A Comprehensive Guide With Best Practices
What to Pay Attention to as Automation Upends the Developer Experience
A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage