People who knows me also knows that I’m a big fan of static analysis tools. Thanks to Patrick Smacchia I had the chance to test NDepend, probably the most complete tool for static code analysis. It is not worthy to enumerate all the features the tool offers, because the documentation and the web site already do a wonderful job with it. Just to mention some of them with NDepend you will be able to measure up to 82 predefined metrics to manage things like coupling, instability, abstractness, dependencies, naming conventions …
Aside all the different, some of them unique, metrics the tool incorporates there are many features that make of NDepend a great tool like:
- Possibility to incorporate new custom rules or modify the existing ones via the Code Query Language, a language with a syntax similar to any SQL language that allows you writing queries against your code structure. CQL makes so easy to create custom rules that there is no fair comparison with FxCop or StyleCop.
- Possibility to introduce CQL constraints in the code that will allow you building really creative rules embedded in your code.
- MSBuild and NAnt tasks to integrate with your TFS or CruiseControl.
- Integration with Visual Studio and Reflector.
- Different graphs that allow you seeing your code in a visual manner.
It is also remarkable the job Patrick has done by creating several demos on how to perform different operations with NDepend to take more profit of it. You can find them online, together with the description of the different metrics and links to technical articles to his blog. It is just pity that you cannot link easier to it from the tool itself. It would be fantastic if in next versions you could just right click in the failing rule and provide an option to reach the help.
Regardless I think the tool is great I must say that I didn’t like some of the naming conventions rules do not follow the guidelines provided by MSDN and one of the greatest books about the subject: Framework Design Guidelines. I also found some of the metrics a little bit arbitrary, like code should have more than 20% of comments, I completely understand you need to put a value to break a rule, but I would love to see more detailed information on how he arrived to the conclusion that some rules should have a specific value instead of another one. Of course, this is part of his .NET knowledge and programming experience. Anyway, this shouldn’t be a limitation because if for any reason you do not agree with a rule, just modify it, disable it … you can do it if you have good reasons for it!!
I like to see the tool not only as a bunch of rules, but as the infrastructure that will allow to build and manage your corporate standards.
I want to finish the post saying that I like NDepend, I think this is one of the must-have developer tools, so if you haven’t tried yet go the website and get an evaluation copy to check it.