I got my hands on a copy of NDepend. Don’t worry, it is a legitimate professional license… NDepend is a .NET code analysis tool that offers a lot of metrics and information on your code base. Here are some of my first impressions.
It starts out easy enough. You have the choice of using it from Visual Studio (it comes with an AddIn installer), from the command line (for analysis during automated builds, I guess) or from a standalone desktop application. I chose the desktop application and was prompted to specify the code base. It analyses assemblies and you have multiple ways of importing them, including some wizards. This is were it started to get tricky because the wizardry did not work that well so I had to import the DLL’s by hand. This is a tool for the sophisticated developer and it shows already at the beginning. After I imported the main assemblies of a project I am working on, I generated my first report.
Here are a few items from the report.
I have seen NDepend before and the thing that scared me then and still scares me now is a thing called Treemap Metric View (which is presented very prominently):
It is supposed to provide you with a single visual on the complexity and state of your code base. The report provides a few other visuals on relationships between namespaces and assemblies which are nice but overly complex and too much 10000 foot view.
The main part of the report consist of results of checks applied to your code base. Don’t freak out: You will see a lot of rule violations! If you can understand it for what it is supposed to be, fine. These rules represent opinions. But they have been found to be very helpful by a lot of developers over a long period of time and thus might have become hard facts. Here are a few examples.
There is this critical warning called Types too big of which the tool found two violations, both being around 800 lines of code long. It is common knowledge that big types should be broken down into parts that each are small and ideally just do one thing. It makes your components way more maintainable and reusable but the main advantage is increased readability, in my opinion. So good job, NDepend! There are many other useful rules, like Methods that could have a lower visibility.
Some rules are debatable, especially ones that are declared as Critical but only in the eye of the beholder. Yes, it is not good to have a violation of the rule Potentially dead Methods, but should it be critical? Who out there does not have unused methods or types sitting around waiting to be reenacted? An interesting one is Constructors of abstract classes should be declared as protected or private. I agree and my Resharper lets me change that in a heartbeat but is it critical issue? Rules come with some sort of source code example of the rule alogorithm which also shows comments so that you can learn more about the rule. In this case it it says the very fact is of a public constructor in an abstract class is useless. Useless is not critical, at least not to me.
I think there is a dilemma here. You need to be a sophisticated developer to correctly use and interpret NDepend. But the very fact that you are of such advanced state means that you already know what you are doing wrong and what you are doing right. The bad developer will get way more violations but does that point him in the right direction? Does that change him?
I like the tool. It gives me something so that I can get into an informed discussion about the state of my code.
Things I would like to check out in the future:
- Baselining. Even if you do not buy into some of the rules and metrics you can see your code base evolving.
- You can incorporate unit test code coverage result into your reports.
- Creating own rules
- Disabling/enabling/configuring/adjusting existing rules