Friday, July 17, 2009

NDepend Review

The Quick & Dirty

There have been a lot of good reviews written for NDepend, so for the sake of efficiency, I'll get straight to the point: NDepend is an amazing tool. It lets you graphically inspect your assemblies and it lets you pinpoint the spots in your code base that need refactoring.

So would I recommend buying NDepend Professional? Yes.

Is there something that I didn't like about NDepend that I think the users should know about? Yes, and that's exactly what I'll talk about.

"So what's not to like about NDepend?"

My only problem with NDepend is that its CQL query engine can only be accessed from the Visual NDepend application. NDepend does let you embed CQL attributes in your applications, but the problem is that I shouldn't have to force each one of my applications to have a dependency on NDepend just because I want to have some code metrics calculations in my build process. Of course, there are a few ways that I can work around that limitation, but the point is that I shouldn't have to make a workaround for something that should have been there in the first place.

In other words, what NDepend sorely needs right now is a publicly-accessible CQL engine API. If NDepend is truly a tool built by developers for developers, then it should have an API that other developers can use to analyze their applications. It's not enough to throw them a rudimentary command-line tool that spits out code metrics in XML--that pretty much leaves developers to write code against the "shadow" of the CQL API rather than write against the CQL API itself, and for me, that just doesn't quite cut it.

Don't get me wrong--the Visual NDepend winforms application is an awesome app--but I'd rather be able to filter through all that information using a single API call rather than have to manually sift through several windows just to find the information I need.

Now the reason why I'm harping so much about the lack of a public CQL API is that my company uses NDepend Professional in its command line builds to ensure that our builds fail when the Cyclomatic Complexity score exceeds 2.5 in any of our projects. The problem is that we want our code quality inspections to be completely automated, and we can't do that unless we have access to the CQL API and can generate CQL queries at runtime. The maximum Cyclomatic Complexity score might prevent our developers from writing complicated code, but there's far more to code inspections than just looking at a single score. What we need is a way to look deeper into the quality of our code base using the hypothetical CQL API with the same ease that Visual NDepend users can browse through their code.

So in the end, I still recommend NDepend Pro as definite buy, but it still lacks a few key features that would make me give Patrick Smacchia's tool the gushing review that other bloggers have given it in their respective reviews. Overall, it's definitely a great tool, but it's not without a few shortcomings.

[Public Disclosure: Thanks to Patrick Smacchia for providing me with a free NDepend Pro license for this review.]

2 comments:

  1. What you want Philip is indeed part of our future plans. The details of what we will propose are confidential so far but I can't wait before making all these public.

    ReplyDelete

Ratings by outbrain