Getting started with NDepend
I recently got the opportunity to try out NDepend and figured I'd write about my experiences.
(Before you can do anything really useful with NDepend, you need to attach a NDepend project to a Visual Studio solution (preferably one with a lot of code!) This is done by hitting the NDepend menu item, followed by Attach new NDepend Project to Current VS Solution, which will create a .ndproj file (default in the your solution folder))
Once NDepend is done analyzing your solution, it provides you a nice HTML report of the state of your code. This report includes a Dependency Graph, a Dependency Matrix, a tree map, highlighting the relative sizes between modules and more. This is nice, because you can share this view with your team when reasoning about code quality:
What's even nicer, however, is NDepend's integration with Visual Studio. Once you've analyzed your solution, NDepend presents you with an Analysis Error List and a Queries and Rules Edit window, working in tandem to tell you what you've missed.
Hovering your mouse over entires in the "matched" part of the window, highlights various statistics of the entry, such as number of instructions, compiled instructions, code coverage and more. Double-clicking it, takes you to its declaration.
Other than finding potentially dead code - which is a great feature that - when acted on - generally leads to lower maintenance costs, NDepend also identifies issues like
(Before you can do anything really useful with NDepend, you need to attach a NDepend project to a Visual Studio solution (preferably one with a lot of code!) This is done by hitting the NDepend menu item, followed by Attach new NDepend Project to Current VS Solution, which will create a .ndproj file (default in the your solution folder))
Once NDepend is done analyzing your solution, it provides you a nice HTML report of the state of your code. This report includes a Dependency Graph, a Dependency Matrix, a tree map, highlighting the relative sizes between modules and more. This is nice, because you can share this view with your team when reasoning about code quality:
What's even nicer, however, is NDepend's integration with Visual Studio. Once you've analyzed your solution, NDepend presents you with an Analysis Error List and a Queries and Rules Edit window, working in tandem to tell you what you've missed.
Double-clicking on a warning in the Analysis Error List, opens the Queries and Rules Explorer, where you can see - and start to address - specific issues:
Once you've found an issue you'd like to tackle - like the Potentially dead Types Dead code rule above - click it once to have it show up in the Queries and Rules Edit window:
Other than finding potentially dead code - which is a great feature that - when acted on - generally leads to lower maintenance costs, NDepend also identifies issues like
- Don't assign a field from many methods (because it could lead to non-deterministic outcomes from not taking in the entire manipulation scheme)
- Avoid having different types with the same name (maybe "Mapper" is too generic of a name of a mapping class? ;-))
- Methods with too many overloads (a common scenario where a code base has grown organically over time without much thought about its evolving lack of quality)
- Instance size shouldn't be too big (again, organic growth)
However, what sets NDepend apart from other tools (Resharper does some of these analysis things too), is that it can track your code over time - is it improving or deteriorating? In this respect, I see that one could use the tool as a basis of ongoing and structural code analysis (instead of a one-off approach), helping an organization to get awareness of quality issues, track progress and identify issues early.
Finally, NDepend lets you write your own quality metrics using a LINQ dialect (this can be seen in the top-most part of the Queries and Rules Edit window). Therefore, as you get more serious about tracking code quality issues, you can configure the tooling to fit your particular needs.
More info?
Comments