NDepend: First impressions

I recently got NDepend to use it as a measurement instrument for a research paper on software engineering I’m doing at the university. Folks at NDepend were kind enough to grant me a free license (thanks) so I’m recording my experience with it.

NDepend looks very complex and it seems it wants to show you all it got. It really has impressive number of features and developers probably have great troubles to show them all without dumbing down the user interface. Going feature by feature won’t get me anywhere so I’ll rather explore how NDepend handle the most interesting features for me: code metrics and code duplication detection.

To test it, I have one MVC project I’ve finished just a few months ago as a side job. It is small CMS application for tourist agency, hastily done which left it with much room for improvement. Let’s see what NDepend says about the project and comment on that.

Code quality

ndepend-query-rulesRules are in form of LINQ queries

Quick summary of methods to refactor

NDepend quickly found the worst methods of the project, fortunately only six of them. Just looking at their names I can see they are trying to do too much: ProcessRequest(HttpContext), LoadHomePageView(), Details() and LoadEditView() are really vague names. What exactly I’m guilty of? Lines of Code are on limit, around 30 which is not too bad (we are talking about 6 worst methods). I try to keep my methods visible on one screen and that is the result. Number of instructions and cyclomatic complexity are similarly low and no method passed the warning threshold. Another metric I keep low when programming is IL Nesting Depth and it shows (no medal from NDepend, just a green dot). I avoid arrow shaped code and use the “get the heck out” tactic. What is wrong with those methods is the number of variables, more then 10 in each method with max of 15. They do too many different things: loading data, parsing, transforming and returning. Each of this segments could be extracted as a new method with descriptive name and the method in question would be much clearer.

Methods potentially poorly commented

Ah, the code comments. I heard everything: from “Comments are worth more the code” to “Comments are dangerous liability”. I got into the “comments-are-bad” camp. If your code needs explaining, you’re probably doing something wrong. For example, you can comment a block of 10 lines of code and explain what they do. But you could also extract that code in the separate method and name it so it’s understandable and no comment is needed. You can explain a clever one-liner with 10 lines of comments but I would rather have 5 lines of code I understand without comments. So, naturally I was happy that NDepend mostly agrees with me and warns only about long methods without enough comments. It found 9 such methods in my code, some even without comments at all. Adding comments would be a quick fix but I’ll try to refactor them first.

Types with too many methods

Only one. But I really did mess that one up. It’s the Session class that contains references to the service objects like BookingService and TranslationService. But for some functions I couldn’t decide in which service to put them in and they ended up in Session class (temporarily I thought). So this class now has Login(), LoadSidebarView() and SaveSettings() functions none of which has anything to do one with another. Maybe the day will come when I could write the project without such class. But it’s not this day.

Code duplication

…is the source of all evil, they say. NDepend uses some clever method for detecting methods that call similar set of functions. I didn’t find visual interface for code duplication detection, instead I had to use Power Tools, a command line program. It did find 21 suspects, few of which really are problematic code. Most of the duplicates have to do with how I load data for view and edit forms. I have LoadEditView and LoadView as separate function that load very similar data. It is something I have to fix. Next it found that the code for booking and enquiry are almost identical and I could probably merge it. Then it found that I use separate functions for booking from the home page and from the offer page but they do almost the same job. And finally, I display recommended offers in header, sidebar, home page and below other offers and NDepend found that I’ve duplicated this function 4 times. Nice catch.


Key points

What I really like in NDepend:

  • Rules are writen in query language, I can use the defaults, change the query temporarily or write my own
  • Rules are heavily commented and even linked to StackOverflow discussions if it is debatable