Friday, January 8, 2010

Review of NDepend


Patrick Smacchia, the creator of NDepend, offered me a free license for NDepend Pro if I took the time to review the product and write this review on my blog. While I have not used NDepend prior to doing this review, given the fact that I have been reading Patrick's blog for quite some time now, along with the fact that I'm a big fan of static code analysis (for the regular identification of problematic areas in your source code), I happily agreed to his offer.


The installation of NDepend is a simple unzip and xcopy to your desired location. Seriously as simple as it gets. Once it's there, fire up the VisualNDepend executable and point it at some .NET/C# assemblies you have.

I decided to run NDepend against a code base that had been handed down to me from a number of prior developers. While the customer is happy and the application has been running in a production environment for a couple of years now, the application is also a serious legacy code development situation, and a great sample project to see what NDepend has to offer for people in my shoes.

So after loading up the half dozen assemblies in the given application, NDepend made quick work of analyzing everything and producing a nice HTML report. It also shows the results in the Visual NDepend results browser, allowing you to quickly navigate around your code base.

Usage Scenarios
After immediately showing a peer of mine the tool what it does, I started rattling off to him the following list of scenarios that describe how I think NDepend can be useful to developers.

#1 - Newbie - Never used NDepend before and barely understands static analysis or any of the metrics used by NDepend.

In this scenario, much like in my code base above, NDepend will quickly point out problematic areas of your source code so that you can immediately start addressing those issues.

Now I'm sure that plenty of readers will immediately start screaming that the metrics aren't useful.

In response, I say that when you're reviewing a code base, and the documentation says that a Cyclomatic Complexity rating above 15 means that a method is complex, and above 30 is nearly impossible to comprehend, that if you're staring at a list of 20 methods with a rating above 30, including 5 with a rating above 40 and 1 with a rating above 80, you can't for a second argue with me that the tool isn't immediately useful in helping focus you in on the sections of your code base that you REALLY might want to stop and clean up. In other words, this is all about quickly focusing you in on the sections of your code base that just aren't good, no matter what your opinion is on the specific threshold for a particular metric.

#2 - Novice/Intermediate - You're familiar with the tool and the concepts and your code base is generally ok per the tool.

In this case, you're looking at integrating NDepend into your (hopefully pre-existing) continuous integration environment so as to ensure constant feedback to yourself and/or your team regarding the "health" of your code base. The value here is that NDepend comes with pre-existing plug-ins for NAnt, MSBuild, and CruiseControl.NET which means you can very quickly get NDepend integrated into your automated process.

#3 - Expert - You're already highly automated and compliant, but feel the itch for more.

In this case, NDepend really shines given the existence of CQL, it's own built in query language, that allows you to run queries against the metrics that it collected during the analysis phase. All of the functionality that #1 and #2 are leveraging is simply based on a set of pre-built CQL queries. But for the expert who is obsessed with perfection, automating their perfection seeking is even better. And being able to either tweak the pre-built queries, or better yet, build a series of custom queries is priceless.

It wouldn't be right to review something and not offer some advice. That is what I get paid for in my real job! Anyway, one big thing that jumped out at me that was annoying was that I quickly found myself lost in the UI. I think that this is due to the specific UI controls and the docking layout stuff that is used by NDepend to try and organize the eleven navigation and results windows. I actually got things so messed up that thankfully NDepend has a "Reset Views" menu item that puts things back to how they were when I first launched it. I also found that once I got the set of windows that I found useful (for scenario #1 above) in view and the rest hidden, things were much smoother.

I think that to help resolve this in general, it would be nice to have a set of additional pre-built views, as there are a couple of task specific ones that already exist, that fit more in line with the three usage scenarios above.

I'd list price as an issue here too, but more from the point of view that I think Microsoft should simply pay Patrick a chunk of change and integrate NDepend into Visual Studio. Now that we've finally got people on board with automated unit testing (hopefully you're already doing this), now's the time for fully automating and enforcing code quality metrics! Unfortunately, unless a developer already knows about and has respect for static analysis, they probably aren't going to hunt down and pay a couple hundred dollars for a tool like NDepend. And then you have teams such as the one I'm currently on that simply doesn't have the budget for ANY tools, so we aren't going to use it either.

So in the end, NDepend simply rocks! While I had issues with the UI, that's something that after 5-10 minutes of use you don't really even notice. The immediate impact that NDepend can have on a code base is priceless. Just think, all of those code reviews everyone says they should be doing but never have the time to do can now be automated, and team members are simply responsible for maintaining the code quality ratings of the code they write.

Thanks to Patrick for giving me the chance to review what turned out to be a great tool. Using NDepend coupled with ReSharper and FxCop, code bases simply have no excuse to end up in the mess that so many of them are today.

No comments: