Static Analysis has interested me for nearly as long as I’ve been coding, so when I was offered to try out NDepend I got really excited. I already rely on the warnings the compiler can give and code analysis rules for my projects and a tool such as NDepend seems like the next logical step. I was not disappointed.

I think that the code analysis rules offered by Visual Studio are powerful and helps improve code quality, but they have a user experience that’s more punishing than encouraging. Code Analysis rules are evaluated after the code is written and after it has passed the compilation – which means when you are sort of done. Then it comes and tells you that you’re not done. That’s demoralising. There’s also no hint of how many rules you did in fact dit pass. The NDepend analysis is different. It is run from the NDepend Dashboard and it shows not just rules violations, but it can also show that your code is good.

A first Impression

The first project I tried NDepend on was Kentor.AuthServices because that’s a code base I know really well. After running the analysis I brought up the code metrics window and what NDepend tells me is that I’m doing fairly good. It’s mostly bright green. And it is so much more encouraging to have a look now at the few red and orange squares than it would be to make a build and find a couple of code analysis warnings that I have to fix. Oh and did I mention that the graphical display is much more appealing than the list of identified code analysis issues in a toolbar?

Clicking on the largest red rectangle brought me to a method that is too long and contains some fairly complex logic expressed in Linq queries. I’d say that it’s a bit hard to read and that splitting it up would help.

I’m proud of the generally high standard of the AuthServices code and NDepend shows me a mostly green view. But it also (painfully) points out areas of the code that i recognize as not so elegant. Even though I know this code base well, it reminds me of those issues that I’ve deliberately “forgotten”.

Looking closer at the graph shows that many of the red areas are linq-heavy methods. I don’t know if that’s good or bad. It can sometimes flag methods that are short and succinct. But they do contain a lot of logic in those few lines of code thanks to Linq’s expressive power. And those methods are not something that can be just glanced at to understand them. They require careful reading because they contain so much information. So in that way NDepend is right, they are complex. I’m not sure that a rewrite would make it better though. Having all the logic in a tight expressive place is sometimes the best way to understand the logic.

Visual Studio Integration

NDepend integrates nicely in Visual Studio as expected. But it doesn’t take over the UI as other code quality tools sometimes do. I’m always confused when I try to help someone having a big well-known code helper plugin installed. With that plugin my favourite short-cut keys does not work any more. Indentation is sometimes done differently. Extra warnings show up that the rest of the team doesn’t see. Having such a plugin installed for only part of a team can be disastrous, as the team members get different views of the code. NDepend is different. It adds a menu item and some context menus, but it leaves the default behaviour as is. And it is clear what features are added by NDepend. For me as a team lead that’s a must. If I am to describe how something is done in Visual Studio to someone else on the team, I of course have to know if it is a general feature or something added by a plugin that I have.

Most of the NDepend functionality is driven from the main NDepend menu, but there’s some context menu integrations too. One that I really like is the ability to quickly analyze if and how a dependency is used in the project. Note how the features is listed under an “NDepend” menu item – no doubt why not all of my team mates will have that feature.

Code Coverage

NDepend also helps visualizing code coverage in the same code map. It is so much nicer to look at than the tree view offered by Visual Studio. Kentor.AuthServices is hardly an interesting project so I brought up the code of the worst project I have access to instead. Recently there have been some tests added to that project, so I hoped that would show. And it does. The new API module which is the surface we are testing against is mostly covered. The new domain model is also fairly good, at least compared to the old domain model which is all read.
NDepend has support for grabbing code coverage data from several different test runners, but that also means that there are a few manual steps to get the test view. First I had to run the tests with code coverage metrics, then export the results to XML format, import them into NDepend, run the NDepend analysis and then the metrics view can be brought up.

Looking at a Bad Project

Now that I have that bad project loaded, I also check the code complexity view. It’s actually not as bad as I had expected, but it’s definitely worse than AuthServices. There’s a few red and orange dots and they can be fixed by refactoring. Looking deeper there’s something worse though: There are large areas that are dark green. Rewriting all that code would be a huge project and NDepend painfully shows what I already knew: This project does not just have a few places with bad code – substandard is the standard.

Installation

A final note is that I found the first impression a bit awkward. There is no installer, just a zip file. And don’t unzip that under program files as of I did because then nothing works. This is documented, but I think that the product would benefit from an installer.

I’m Keeping it!

After the tryout I’m definitely going to keep NDepend installed. It provides some valuable features and possibilities and it doesn’t interfere with the every day coding experience. As an architect I’m sometimes have to analyse and get a grip of a code base where’s there’s no documentation and no team members available any more. In those cases I expect that NDepend will be a great tool to use. I’m also sure that I’m going to use it to keep an eye on the overall code complexity and find those areas that need improvements. There are also many more features that I am yet to discover – the tool is powerful and contains a lot of functionality. Many thanks to NDepend for letting me try this fantastic tool and if you want to try it out too there is a 14 day trial available.