Geeks With Blogs

News

This blog has moved to ericnelson.wordpress.com

 Subscribe in a reader

Add to Google Reader or Homepage


Links
View my teams slideshare
These postings are provided "AS IS" with no warranties, and confer no rights.



IUpdateable has moved to ericnelson.wordpress.com Please visit http://ericnelson.wordpress.com

[Check out other guest posts if you like this one. They are often better than mine!]

One thing I miss about being the Technical Editor of the UK MSDN Flash is interacting with smart individuals to get their technical article ready for inclusion. It occurs to me that I use GuestPosts on my blog to get a similar “fix” :-) It is time for another fix :-)

In this case the author is Patrick Smacchia, a very smart developer who happens to be the the lead developer for the rather amazing tool NDepend (and an MVP in C#). I was and still am amazed by the power of NDepend which I first came across a three years back. I found it particularly beneficial when my role involved “reviewing” code created by teams outside of Microsoft but it has many other uses. A chance conversation with a UK development team at a conference made me realise that awareness of NDepend remains surprisingly low. Hence I hit on the idea of getting Patrick to do a guest post.

NDepend gives you many pretty pictures (and useful!)

image

But for me the big win is in the query capabilities. NDepend supports the Code Query Language (CQL) for maximum flexibility. 
With CQL in Visual Studio, shed light instantly on any fact about your code:

  • Which method has a too high cyclomatic complexity or too many lines of code?
    • SELECT METHODS WHERE CyclomaticComplexity > 12 OR NbLinesOfCode > 30
  • Which method have been refactored recently and are not well covered by tests?
    • SELECT METHODS WHERE CodeWasChanged AND PercentageCoverage < 100

See the wood despite the trees with NDepend (and vice versa)

by Patrick Smacchia

image[4]

I had the chance to start programming young, at 10, thanks to my dad who is a … programmer. It was a huge chance because child brain is much more open than adult’s one. For example, the best juggler in the world, Anthony Gatto , had his first juggling balls at 3. By 8 he was already quoted in the Guiness Book of World Record.

Basic code elements like if, pointer, goto, char, string etc, became concrete parts of my world. At my teenage age, I had the chance to develop tons of different fun projects, including video games and 3D and fractals demo, mostly coded in Amiga’s 68000 assembly. By 16, I discovered also all the elegance of mathematics. A choice had to be made, should I be a math teacher/searcher or a professional software developer? By 19, I opted for Software Engineering University.

I explained this short bio to come to this conclusion: until I was programming professionally at 22, I thought that programming was all about if, pointer, goto, char, string etc. I was micro focused on code. Quickly, I discovered that in the industry, code bases were much larger and complex than everything I saw until then.

I needed to develop a macro understanding of these large C++ legacy code bases I had to maintain. And my best friends if, pointer etc were not enough to helped me get deep in a legacy project. I needed more, I needed tooling. The only tool I had at that time was Visual Studio C++ v4. It had only a basic folders and files organizer, now known as the Solution Explorer. This didn’t help me to understand things like:

  • What were the important concepts modelized in the code base?
  • How concepts were related to each others?
  • What were the former programmers intentions and design choices to
  • Group these concepts into components?
  • How components were bounded?
  • How states were mutated at runtime?
  • What were the impact of recent and less recents evolutions?

I didn’t know yet, but this frustration provoked by a lack of tool was the first seeds of the tool NDepend I began developing in April 2004.

One more time in 2004 I got frustrated to have no macro-understanding about the code base I was working on. At that time a few members of the team of the project I was working on had this knowledge. And this precious knowledge was strategic, it was delivered with a spoon.

NDepend was really rudimentary in April 2004, and was just producing a few code metrics and graph. The project was OSS and quickly a community of enthusiasts appeared. Hurrah! I was not the only one to realize that code contained actually more than if, pointer etc. Others fellows thoughts also that a code base contained enough information to reverse engineer it in order to get a macro understanding of what was happening.

This OSS success was a good incentive to work ridiculously hard to deliver the first professional version of NDepend in Feb 2007.

Hopefully now, I can make a living from my work and my passion.

Concepts like macro understanding, or tenets like the code is the truth, become more and more popular nowadays in the .NET sphere.

NDepend is often deemed as a static analyzer tool because it gathers information from the code and can infer something useful from it, like custom rules validation. I always thought that NDepend is a particular kind of static analyzer that would deserve a different name. Because static analysis is really about finding flaws in the runtime behavior by analyzing the code without executing it. NDepend is more about finding design flaws that will lead to over-complex and error prone code that will create maintenance problems. And for all software shop, maintenance is a big and costly challenge!

Instead of explaining in depth what a tool like NDepend can do, I invite you to download the trial version now and analyze the code you are working on. I bet than in less than 5 minutes the tool will make obvious something about your code base you didn’t know.

  • Are you sure that the DB APIs are only used by DB components?
  • Are you sure that the recent evolutions didn’t introduce major flaws in the original structure of the code?
  • Are you sure that the code base doesn’t contain fat and entangled portion that again and again, slows down significantly any evolutions?
  • Are you sure that the code recently produced is sufficiently well tested by automated tests?
  • Did you code review all addition and changes since the last major release?

All this precious information is stored in the code. Only appropriate tooling can shed lights on all these.

Related Links

Patrick also supplied some great examples of using NDepend.

Posted on Tuesday, August 3, 2010 10:07 AM .NET 3.5 , .NET 4.0 , GuestPost | Back to top


Comments on this post: GuestPost: See the wood despite the trees with NDepend

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Eric Nelson | Powered by: GeeksWithBlogs.net