Last week I received an email from the folks at NDepend offering a free license to try out NDepend and write about it. Having never heard of the tool, I was intrigued, then excited after I realized what NDepend does!
What is NDepend?
NDepend is a Visual Studio Plugin (plus some external tooling) that provides detailed code quality analytics, graphs, and other forms of visualization.
The core functionality of NDepend lies in the Code Rules. Code rules work by querying your assemblies with Code Queries, which are a really slick adaptation of Linq to traverse and inspect the characteristics of your code base..
A single rule looks like this:
What is NDepend?
NDepend is a Visual Studio Plugin (plus some external tooling) that provides detailed code quality analytics, graphs, and other forms of visualization.
The core functionality of NDepend lies in the Code Rules. Code rules work by querying your assemblies with Code Queries, which are a really slick adaptation of Linq to traverse and inspect the characteristics of your code base..
A single rule looks like this:
Pretty straightforward. Every rule in NDepend uses code queries to formulate the parameters and warnings the rule produces -- and I must say that the documentation in each rule is one of the most fantastic facets of NDepend. I have yet to encounter a rule that didn't provide adequate explanation and suggestions for how to fix the issue.
A clean installation of NDepend comes with almost 300 rules enabled, so even if you don't dive in and write your own rules, the initial collection is more than adequate to cover the needs of just about any project. They are grouped categorically, and can be enabled/disabled/edited to meet your needs using the Queries and Rules Explorer.
A clean installation of NDepend comes with almost 300 rules enabled, so even if you don't dive in and write your own rules, the initial collection is more than adequate to cover the needs of just about any project. They are grouped categorically, and can be enabled/disabled/edited to meet your needs using the Queries and Rules Explorer.
So what does it do for me?
There are a few benefits that can be reaped from NDepend.
1.) Regular execution of NDepend analysis can prevent degradation of code quality
You can also integrate NDepend into your build cycle so that rule violations are treated as broken builds, to effectively curb the introduction of nightmare code. (Uber long functions, tightly coupled classes, excessive complexity)
Get used to using the Dashboard to get a quick glance of how you're doing in terms of rule adherence and coverage.
There are a few benefits that can be reaped from NDepend.
1.) Regular execution of NDepend analysis can prevent degradation of code quality
You can also integrate NDepend into your build cycle so that rule violations are treated as broken builds, to effectively curb the introduction of nightmare code. (Uber long functions, tightly coupled classes, excessive complexity)
Get used to using the Dashboard to get a quick glance of how you're doing in terms of rule adherence and coverage.
2.) The visualization tools provide a powerful means of understanding and correcting architectural issues
There are several that come to mind that are indispensable in terms of utility because they're highly configurable and can be used to understand your architecture in better detail without having to graph it out yourself.
The Metrics View provides a very approachable spatial view of your code along many analytical options. Below is a cyclomatic complexity Metrics View of OSCADSharp.. It's a great way to spot problem areas at a glance and identify code that should be refactored.
There are several that come to mind that are indispensable in terms of utility because they're highly configurable and can be used to understand your architecture in better detail without having to graph it out yourself.
The Metrics View provides a very approachable spatial view of your code along many analytical options. Below is a cyclomatic complexity Metrics View of OSCADSharp.. It's a great way to spot problem areas at a glance and identify code that should be refactored.
(I also very much like the Metrics View for percentage of code coverage as well.)
Another visualization tool is the Dependency Graph, which is an easy way to view relationships of namespaces, types, assemblies, and more..
Another visualization tool is the Dependency Graph, which is an easy way to view relationships of namespaces, types, assemblies, and more..
Closely related is the Dependency Matrix, which might not be as pretty but the big advantage of the dependency matrix is that it's more directed at identifying unhealthy dependency relationships between types, rather simply presenting information.
Admittedly I'm still no expert at using NDepend. I imagine as I use it more I'll begin to better understand how to use the tools to improve code quality.
My Thoughts
Between the deep collection of rules, visual tooling, and analytics reporting, using NDepend is like having a digital code-quality advisor by your side.: One who is an expert at his craft.
After using NDepend for about a week and a half, I feel like I've barely scratched the surface of how I can use it. It certainly blows the builtin Visual Studio analysis tools out of the water.
I could certainly see myself using NDepend with a medium to large size development team as a mechanism for enforcing code quality. (By means of running the rules with the build)
Though admittedly I feel NDepend is overkill for the majority of developers. It's definitely aimed at the top of the skill curve, and I imagine in a team setting most devs wouldn't necessarily leverage the analysis tools to improve their code, so much as they would react only when the build is broken due to breaking NDepend rules. One thing I would really like to see is a variety of license options that offer a limited subset of capabilities for scenarios where only a few devs will actually use the visual tools and edit queries, but all devs need to adhere to the rules on build.
OSCADSharp is slowly transforming with the help of NDepend. Stay tuned for a few more posts about my adventures with NDepend.