Earlier this year Patrick Smacchia from NDepend contacted me on linked-in. He would offer me a professional license to blog about his product. Now I finally have the time to keep my end of the bargain.
Since the features are so numerous I will not cover them all at once. After loading my Visual Studio solution a report is shown. This report is a good start to improving your solution.
First a summary with some tips to get you started.
Below the diagrams to visualize your solution. There are a dependency graph, dependency matrix, treemap metric view and abstractness vs instability. Visual Studio Ultimate sometimes has problems with larger solutions (read:crashes) whereas NDepend takes it’s time but finishes the job. Especially the dependency matrix can be a life saver in complex systems.
Then the application metrics. I noted no code coverage was available. VSExpress does not provide it, but I can use other tools. Installed OpenCover and converted the result to NCover 1.x with this XSLT only to discover NCover version 2 and up was supported. I expected more. Then again: paying for NDepend professional and holding out on other licenses?
Last up are the rules. I managed to generate 14 warnings with just 32 lines of code :shock:. That is what I’m going to change in the rest of this post.
Every warning is described by it’s name, the query used to find it and the detailed information about the class that violated the rule. After changing your code you can review the rules by (re)building in Visual Studio and then Run Analysis on Current Project (F5) in NDepend.
Some tips are not so useful like Classes that are candidate to be turned into structures when an attribute is on it that requires the type to be a class or the type has a parameterless constructor. Or Types that could have a lower visibility to make unittest classes internal (and unusable). Others are very smart like Mark assemblies with CLSCompliant and Potentially dead Methods. Using the CQLinq language you can adjust or create your own. Some warnings can be suppressed by using attributes from the NDepend.API assembly.
In the end I was left with 5 warnings about my unittest. Those I can ignore.
Conclusion so far
Personally I prefer to use the build-in features of Visual Studio 2012. But the Express edition is very limited and the perfect candidate to expand with NDepend. Expect no integration as Microsoft disabled this on their free IDE. NDepend can run as a standalone program and still deliver.
Other features will be posted soon.