The Next Level of Code Analysis using ‘NDepend’: An Interview with Patrick Smacchia
Posted by: Suprotim Agarwal
in Category Product Articles
Abstract: In this post, Suprotim Agarwal (ASP.NET MVP) interviews Patrick Smacchia, a C# MVP about the NDepend product.
The Next Level of Code Analysis using ‘NDepend’: An Interview with Patrick Smacchia
In this post, Suprotim Agarwal (ASP.NET MVP) interviews Patrick Smacchia, a C# MVP about the NDepend product.
NDepend is a .NET code analyzer tool on steroids. This tool analyzes your .NET assemblies and the compiled source code, with a variety of metrics. I had been using FxCop till date for code analysis, before I was introduced to NDepend by its creator, Patrick Smacchia, a C# MVP. Something that impressed me the most was CQL and code metrics, which can be used to examine complexity and dependencies in your code and improve the overall quality of your code. This tool will in fact change the way you glance at code!
In this article, we will discuss the NDepend product with Patrick and understand how this product takes code analysis and code metrics to the next level.
Suprotim: Tell us more about yourself and NDepend. How did the product evolve?
Patrick: My name is Patrick Smacchia, I am French, 33 years old, and I basically write software since I learnt to write thanks to my father who is also a programmer for more than 35 years by now. The NDepend project started in April 2004. At that time I was consulting and I wrote NDepend as a quick project to demystify the massive and extremely complex code base of a client. I was interested to get basic metrics such as NbLinesOfCode but also Robert C Martin metrics about abstractness vs. stability. This first NDepend version was pretty useful and I released it OSS online straight. The tool then became pretty popular, also partly because at that time the .NET community was lacking development tools. I did the math and if a few fraction of users would buy a few hundred US$’ professional license, then I could start making a living on it and invest all my time in development. After a whole year of very hard work the version 2.0 RTM went live in February 2007 and hopefully the business model wasn’t flawed. I summarized all this in this blog post http://codebetter.com/blogs/patricksmacchia/archive/2008/11/03/advices-to-developers-on-starting-an-independent-software-vendor-isv-business.aspx and I hope it can foster developers mates to innovate and start their own ISV. Since then, the company grew and we worked a lot on both features and usability of our flagship product NDepend.
Suprotim: How does NDepend fit in the Software Development Process? What is CQL and how does it relate to the product?
Patrick: NDepend is all about understanding and controlling what really happens in your development shop. The idea is to fetch relevant information from the code itself. The tool has 2 sides: The Visual side where the VisualNDepend UI lets you analyze live your code base, with graph, matrix, metrics panel. These visual panels with dependency graph, matrix and metric treemap, help a lot churning the code. Some screenshot can be found here.
Fig 1: Selection by Metrics and display the set of methods selected on the Metrics View
Fig 2: Using the Dependencies Structure Matrix to understand coupling between assemblies
Fig 3: Selecting the list of methods where code was changed between 2 versions and visualizing source code modifications with Windiff
Fig 4: The Visual Studio Add-In
VisualNDepend comes also with Code Query Language CQL. CQL is really at the heart of the product. CQL is to your code what is SQL to your data. You can ask for example which method has more than 30 lines of code by writing the CQL query:
SELECT METHODS WHERE NbLinesOfCode > 30
And if you want to be warned of such big methods you can transform this CQL query into a CQL rule this way:
WARN IF Count > 0IN SELECT METHODS WHERE NbLinesOfCode > 30
CQL covers a wide range of possibility, from 82 code metrics to dependencies, encapsulation, mutability, code changes/diff/evolution or test coverage. For example asking for methods that has been changed recently and has not been covered by tests is as easy as writing:
SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100
NDepend comes with more than 200 rules per default and you can modify existing rules and add new rules at whim to fit your needs.
The other side of NDepend is its integration into the Continuous Integration/Build server process. The idea is to get a daily and highly customized HTML report where you can see at a glance if some CQL rules have been violated and to get also some metrics about quality or structuring. This is how one can master what is really happening in its development shop
Suprotim: Many teams have assemblies built in both C# and VB.NET. How does NDepend analyze such applications built using multiple languages?
Patrick: NDepend takes as input any .NET assemblies, no matter the language it was written in. 95% of the information gathered by NDepend comes from assemblies themselves. NDepend also parses source files but only a few metrics are gathered from source: Source Code Cyclomatic Complexy and Comment metrics. So far only C# source files are parsed and we plan VB.NET source files parsing for the next months. More details about all this can be found here.
Suprotim: How would you compare NDepend with other popular tools like ReSharper and FxCop?
Patrick: I am a big fan of Resharper and I like to think that what is Resharper doing locally, at the level of method, NDepend does it at large scale level, on type, namespaces and assemblies. Resharper typically warns about a logical if expression flawed where NDepend typically warns about a component too big or too entangled.
FxCop comes with more than 200 hundreds pre-defined rules. FxCop rules mainly inform you how to use the .NET framework and you have a few quality rules also. NDepend CQL rules are more focused on your code itself although 30 pre-defined CQL rules covers some .NET Framework usage good practices. NDepend will typically let you know that some abstractions have to be created to avoid over-coupling, while FxCop rules will typically let you know that you should use a StringBuilder to concatenate strings inside a loop instead of using the ‘+’ operator.
Suprotim: How does NDepend help you in Agile projects where most of the efforts are on delivering code?
Patrick: Agile development is all about rationalizing the work to avoid repetitive burden tasks. Agile fosters efficient communication between developers and continuous correctness check with automatic tests. The NDepend’s CQL language lets developers express their intentions in a formal way. For example developers can create a specific rule to avoid that UI code uses directly DB related code. But as a big bonus CQL rules are active, I mean you’ll know automatically when a rule will be violated. So not only CQL rules improve the communication between developers but it also prevents code erosion by discarding the burden of manually check that developers respect intentions and quality effort put into the code.
Suprotim: Tell us about a recent experience with NDepend in a real-world environment? Can we see a case study?
Patrick: There are various NDepend users profile, from the independent consultant to the massive team cluster composed of hundreds of developers and millions of lines of code. Part of the NDepend challenge is to let users cop with very large code base. To do so we constantly invest in the performance of our code.
We recently have feedback from one of this massive team and I wrote a blog post about their experience here: Using NDepend on large project, a success story. I also had the opportunity to recently help a 60 developers team cranking with NDepend concepts and I wrote about this experience here. Basically the more complex is your code base, the more you need tooling such as NDepend; especially if you wish to spend efficiently your resources on large scale refactoring to transform a large legacy made of messy code into a sane development shop.
Suprotim: Can dotnetcurry.com viewers see a Live Demo of this tool? Do we have an NDepend forum to discuss this tool?
Patrick: On the main page of our site we link a dozens of short 3mn screencasts to demonstrate how NDepend handles various scenarios, like comparison of 2 snapshots of a code base, dependency browsing or quality metrics checking.
Suprotim: The NDepend product is loaded with features and metrics. What are your plans in 2009?
Patrick: In 2009 Q2, the 2 NDepend’s brothers XDepend (for Java) and CppDepend (for C++) will see the light of the day. A public beta of XDepend is already available on the XDepend website.
NDepend is often qualified as a polished tool by its users and in 2009 we wish to continue investing in even more usability. With System.Reflection everyone can write a quick static analyzer of .NET code in a few days such as what was NDepend in its early days. What we learnt the hard way is that usability can only comes at the cost of years of solid development and IMHO usability is what makes the difference. Part of our 2009 usability plans is to integrate nicely Visual NDepend panels into VisualStudio but one can expect also dozens of tricky featurettes.
We also have several major innovative features in the pipe but for some confidential reasons I cannot unveil them by now. For the benefit of all .NET developers (our team included), the .NET tooling scene is very active these days and we will continue investing into features that so far, no other tools have.
I hope you enjoyed this interview with Patrick. Here’s some simple advice to all of you: Understand and list down the metrics that are important to your product/project. Then strive towards achieving them with a tool like NDepend that will keep you on track!