I got an opportunity to try out the full version of NDepend. You can read a lot about it elsewhere, but I always like to look under the hood and write about it from my own perspective. I have used some free tools before, namely FxCop and StyleCop, so I’d also like to do a little comparison as well.
Let’s get this one over with quickly: I truly hated StyleCop. I code in a very clean and consistent style, and I try my best to adhere to conventions. Parts of it I picked up over the years, parts of it just make sense or look nice. I also love the built-in code formatting of Visual Studio, I always use the default rules. It was about a year ago when I tried StyleCop, so I don’t remember everything clearly, but it didn’t agree with me or Visual Studio in several ways. To name one, putting using statements inside a namespace looks totally crazy to me. I knew I could have customized it, but I didn’t think that putting any effort into it would be worth it, I already had my style and Visual Studio’s code formatter, so I stuck with those.
On the other hand, I really loved FxCop. It is very easy to use, it has rules that really make sense to me, and it is built into Visual Studio by default. It only focuses on one goal, showing you warnings if you do something bad, and it’s really good at that. It barely even has a UI. You can also extend it with custom checks, developed in .NET of course.
Now let’s take a look at NDepend. It’s not the easiest tool to use, but that’s pretty much all the bad there is about it. It doesn’t care about my source code formatting, which is a plus for me . It is a static code analysis tool, like FxCop, but it’s also a lot more than that.
Basically, it has lots of rules and lets you verify whether your code violates any of them, it can also integrate into Visual Studio and the building process, pretty much like FxCop. The big innovation is the rule engine, CQLinq (Code Query LINQ): rules are LINQ expressions. When I first heard about it, I thought it’s nice, but I had my doubts, I thought it’s hard to do complex stuff with that, but I was wrong.
When NDepend analyses code, it first builds a huge object graph about your code (see NDepend.CodeModel namespace). Think about reflection, plus a lot more. It has dozens of extra properties about everything. There are standard metrics, like the number of IL instructions and cyclomatic complexity of methods, and even more advanced stuff, for example, IMember.CouldBePrivate tells you if a method or other kind of member could be declared as private. This kind of information needs a lot of effort to gather, some of the things which are full-fledged rules in FxCop, are readily and easily available built-in properties in NDepend, so you can focus on the real logic in the rules.
So when you have the code model, you can start running queries with a LINQ syntax. I have to admit that I only learned about the let keyword when I started using CQLinq. This single language construct is the key thing, it lets you step away from simple SQL-like stuff and create very complex queries. After I looked at the built-in rules, I didn’t have any more doubts about the possibilities of NDepend. I’m pretty sure that whatever FxCop knows, NDepend knows that, too. And whatever way you can extend FxCop with a .NET assembly, you can also extend NDepend with a CQLinq query, which is just as powerful but a lot easier to use.
NDepend comes with 200+ built-in rules. With the value-added code model, many queries can be quite simple as you can see on the image on the right, but of course there are very complex ones, too, and they are open sourced and well commented. And the best thing is that you can edit the queries in real time, with code completion, and see the results immediately in a grid, which even knows about how to display which kinds of data.
CQLinq is awesome, but NDepend has a lot of knowledge about your code, so it doesn’t stop there, and gives you a lot more visually. For example, it can draw dependency graphs, I love dependency graphs. Then it can draw dependency matrices, treemaps, etc. And everything is interactive, clickable.
NDepend also supports continuous integration testing. It has an assembly comparer UI, but the real deal is also built into CQLinq. For an analysis, you can define a baseline, and then all the changes can be queried from the exact same code model. For example, ICodeElement.WasRemoved() returns if the code element in the baseline doesn’t exist in the current version, and there you have it, detecting breaking changes comes down to a very simple CQLinq query, too.
And last but not least, it has a very nice UI, with lots of context sensitive help and lots of online documentation as well. All in all, NDepend is just awesome.