Over the years, I’ve used several development tools. Consequently, I saw how drastically they evolved from simple code editors to very smart and extensible IDEs. The first one I used from Microsoft world was Visual Studio 6, and I’ve been upgrading every release till Visual Studio 2022, which I use daily.
Although VS has been improved a lot when it comes to ensuring code coverage and quality, nothing compares to third-party extensions specialized in code analysis. There are trendy names out there, and sadly just a few open-source alternatives, but I’ll be talking about one of the big proprietary ones, the NDepend.
This article is not a training or tutorial of any sort, but a review of my first impressions of using it for the first time, thanks to the Pro license cordially offered by its creator, Patrick Smacchia, who found me through my article about SOLID. Speaking of which, one of the things that motivated me to try NDepend was the fact he mentioned how much it could help when it comes to respecting the SOLID principles.
What comes with NDepend?
The “Swiss Army Knife” for .NET Developers, Architects and Teams.
NDepend seems to have its evolution path alongside .NET. This can be seen from the release notes, dating versions since 2004. I downloaded version 2021.2.2 and installed the extension on Visual Studio 2022 Preview. It was pretty easy and ran smoothly. One of my concerns was that it would make VS heavy, but I was surprised by how light it kept it. Among many features, is worth mentioning:
- Detecting Code smells
- Technical Debt estimation
- Software metrics
- Integration with CI tools and Reporting
- Dependency visualization using Graphs / Matrix
- User-defined rules written using LINQ queries
Good news to my old project
I wanted to test the usability of this tool and how much it would drive me without having to watch online training. Everything you will read from now on is what I got by just exploring the features I found. There was no better way to test its capabilities than using it against the biggest project on my GitHub. EcommerceDDD is a showcase of a full-stack application I use to combine several cutting-edge technologies and architectural patterns, more than enough to feed NDepend.
Attaching it to my solution
After finding NDepend on the extensions menu, the apparent option was to “Attach New NDepend Project to Current VS Solution”. Then Git showed me that a folder named NDependOut was created among my files. Initially, it was a minor concern, but I’ll talk about how I handled it further.
Analyzing assemblies
I was prompted with a window that listed all the seven assemblies it could analyze and put the single testing project aside on the right. It also discarded the ASP.NET project I used to add the Angular spa project to the solution. There’s nothing it can do there, but if it was a regular ASP.NET website, it offers a link showing how to proceed to have it covered afterward. I clicked on Analyze seven .NET Assemblies.
Analysis finished, it prompted this wizard to display the main features and their descriptions. Of course, I started from the Dashboard.
Dashboard
The dashboard initially looks like an airplane cockpit, but I’m sure I’ll get used to it after a while. Of course, things start to require some training to use all these metrics and charts, but the top squares with colored numbers are pretty intuitive.
Rules Explorer
Then, back to Extensions > NDepend menu, I hit the Rules Explorer item, which I could enable/disable the rules I wanted my code to match.
Dependency Graph
This feature is undoubtedly one of the shiniest. It builds a nice dependency graph of the assemblies, and it’s interactive in a sense you can click on the grouped blocks to view the dependency paths. Everything is straightforward and colored to give you the big picture.
Time to refactory
Show me the issues
I decided to tackle the critical rules that the project was violating. Yes, there were several warnings for issues, but that doesn’t mean you have to solve them in real life. It’s a gradual process that must consider priorities and severity.
So, clicking on the red number showed the left-tab panel that showed interesting things. One that called my attention was a correspondent pre-loaded LINQ query that uses a feature named CQLinq for stringing down issues over a list.
I need an advice
Luckily, the first warning was about a constructor with several arguments, but actually, it is my Unit Of Work and its instance is meant to be resolved by dependency injection. No big deal.
Also, you can click on the View description button to have a nicely written explanation of the rule you’re violating, how you can fix it, and why. This feature is by far one of the features I liked most. Even after years in the field, there is still much to learn.
Rule matching
Among the list of issues, one rule warned me that I had two types (classes) with the same name, and it happened because I transferred that class to another project to make it simpler but forgot the former type behind in its own (now deleted) project. So I could rapidly find the class to remove it. It’s interesting how it can evidence `Single Responsibility Principle, among others equally important.
Removing the footprints
As I mentioned in the beginning, NDepend creates the NDependOut folder, which I didn’t want to include in my project. So, I added it to .gitignore, it solved the problem.
*.ndproj
/NDependOutFinal thoughts
NDepend is undoubtedly a great surprise. From the release list, it’s clear the development team is constantly working to improve the tool and catch up with the news from .NET world, as we always have done. This tool not only helped me identify code flaws and enhance my project but also gave me the feeling of improving myself as a developer.
The custom way you configure how picky it will be on your project is also great. There are tons of features I didn’t even mention in this article, as you can see on the complete menu above. With time and after I explore them, I hope to be proficient enough to talk about them in detail in the next articles.