I often get asked which tools I use for development or reviewing of existing codebases. This question is often hard to answer directly, as every situation is a bit different. However, I thought it would be worth trying to revisit the tooling topics to help others possibly improve their environments by knowing the tools I find helpful. This post will be the first of a limited number of occasional posts on tooling. With the primary focus of my topics still being with ASP.NET, MVC, and performance. If you find these helpful, though, I'd love to get some feedback.
NDepend: Code Analysis
In this post I am going to take a look into the product NDepend. Just before the release of their new 7.1 version I was invited to provide feedback on a few of their new features. As part of this process, I worked with the vendor to better understand their goals, and to help ensure that the results of its analysis are beneficial to developers.
It is easy to get overwhelmed with the functionality provided by this tool. I've used it myself for years, but it has been hard to quantify the direct value of the solution truly. With the most current release, they have added some great new functionality that helps to eliminate that situation. A few of my favorites are the Technical Debit Estimation, Code Rules, and visualization. As part of this post, I thought I'd share how I use NDepend to improve code quality, to monitor the health of our installations, and to help with the evaluation of an unknown code base.
But "Code Quality" is Subjective
Before I get into any of the specifics of how I use the tool, I think it is important to look at the concept of "Code Quality" as it relates to your particular project. We have some metrics that are often thrown around when it comes to the quality of a given code base. Things such as Cyclomatic Complexity, IL Nesting Depth, and even more granular into the specifics of the number of methods, the complexity of namespaces, and much more. Sometimes as developers we write things that "only need to work," and maintenance ability isn't a primary concern. For these, we might not be as concerned, however, for things that might have a future we want to be able to get a better glimpse into the codebase.
How I Use NDepend
With that out of the way, I want to focus on a few key features of the most recent releases of NDepend and how I use them. I'll be including screenshots from an internal project of mine, FlightFiles that has been in development for around two years. The following are highlights of things that have been helpful for me; your results may differ.
This is a new feature to NDepend, and something that I like. After setting up your project and having NDepend analyze it, you are given a percentage value of "Technical Debt" based on the rules associated to the project. If you have performed multiple analysis operations, you can see the change in trend. This system classifies technical debt as code that is in violation of rules that are defined and evaluated for your current project.
Using the "Explore Debt" option you can drill into the specifics of what they consider to be debt. During this process, they provide an Issue count as well as an estimated time to clear the debt. In the example provided above they provided a 5d 4h estimate for resolution of the debt in our analyzed solution. In reviewing the recommendations, it appears that the provided debt estimates are realistic. I see two direct benefits of this functionality; first, you can get a quick glimpse of where your code stands against some best practices. For those that have used StyleCop, or FxCop in the past, think of those tools on steroids. Secondly, this tool allows you to confirm, as your product grows, that you are not adding to technical debt. I find this incredibly helpful with legacy code bases in situations where better patterns and practices are desired.
Identification of "NotMyCode"
When looking at modern projects, we are using more generated code. Things such as Entity Framework Migrations, Service References, or otherwise. When we analyze our code, it is often helpful to "exclude" those items from our metrics. Migrations for example are what they are, and sometimes there isn't much that can be done to clean them up, they might not also meet the standards used elsewhere in relation to comments and documentation. With the "NotMyCode" query, and information provided in NDepend you can get
I'll spare you the detailed image for this project. However, another key feature is an ability to display a dependency graph of your project. This chart allows you to quickly identify the various dependencies that your application might have, as well as how deep the dependencies are. As many users look towards migration to ASP.NET Core and other cross-platform initiatives, this can be great.
If code quality is a key concern for you, and you want to have a great way to query and analyze your code for best practices this is a great tool for you. It takes time, and experience to master, but the new release provides metrics and information that make it easier to understand and work. Feel free to share your suggestions below.