Hi
I've been trying out NDepend, been reading a few blogposts about it and even heard a podcast. I think that NDepend might be a really useful tool, but I still don't see where I would use it.
How do you use it? Do you use it, why? why not?
I would like to hear about some down to earth real world examples.
I've found it useful to visualize changes between versions of assemblies. Even for a snapshot of changes in a given release...
I think it shines in a Continuous Integration environment where you can set up CQL queries to measure code metrics you're interested in (Cyclomatic Complexity, Long Methods, etc.), and then you can measure your improvement in those areas over time.
I've used NDepend extensively over the past few years. Basically it is a dependency analysis tool, and so this can help you with lots of dependency related issues.
One of the main things I use it for is to examine the dependencies between my assemblies, types and methods. This helps me to keep a view of whether coupling between types is out of hand, and also helps me spot refactoring opportunities.
When embarking on a massive refactor, e.g. extracting.moving types to other assemblies, this lets you see what depends on what so you don't have to do the old "move my types to another assembly, then try and compile and see what breaks"
NDepend also has a great visual matrix for viewing this sort of information.
Additionally, it has a fantastic query language, CQL, which lets you write custom queries. These can be simple things such as "show me all methods that call this method", to queries to highlight dead code, queries on cylcomatic complexity, coupling, etc, and much much more.
In turn, it can be integrated into a build process, so you can have build warnings/failures based on CQL queries, such as "fail the build if a method has more than 100 lines of code but no comments" (this is an example - I'm not suggesting this particular metric is a good thing).
It can also import code coverage data and give you a visual representation of areas with little code coverage, as well as allowing you to run CQL queries against code coverage information (e.g. show me methods with less than 70% code coverage)
You can also load your current build of your project, and a previous build, and run queries between them such as "show me all new types that have <70% code coverage" - this helps you introduce tighter rules on existing codebases.
This is a fantastic tool, and isn't too difficult to learn. It is scary at the start, just because of the sheer volume of informaiton it gives you, but is highly recommended.
Actually this tool is helpful if you have e.g. interface which is using by another part of application developed by different person/vendor. Everytime you want to change the interface you have to find out who is using your interface to avoid breaking its code (assembly won't build) This is applicable for bigger projects.
I also find it invaluable in understanding the structure of complicated method calls. I can call up all methods transitively using a particular method or field, for example, and can see if there are possible problems with circular calls, or unwanted dependencies, or paths which are more convoluted than necessary, etc.
The dependency graph is also now interactive, so I can remove methods which I am not currently interested in, and move others around to give a good visualization of what is going on.
This tool is helpful when your application has a huge number of assemblies. It helps me find out the code dependencies and as well as changes between releases