Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Do you use NDepend?

Tags:

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.

like image 651
Karsten Avatar asked Jan 12 '10 15:01

Karsten


People also ask

Why use NDepend?

NDepend not only has a great static code analysis tool, but also provides a way for veteran developers and aspiring architects alike to adhere to coding standards along with a way to integrate a company's coding standards into the tool using CQLINQ.

What is NDepend tool?

NDepend is a static analysis tool for . NET managed code. The tool proposes a large number features, from dependency visualization to Quality Gates and Smart Technical Debt Estimation. For that reasons the community refers to it as the "Swiss Army Knife" for . NET Developers.


1 Answers

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.

like image 113
Rob Levine Avatar answered Sep 22 '22 01:09

Rob Levine