Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Are Code Statistics Useful?

My team had a conversation about code statistics at lunch the other day, specifically about Cyclomatic Complexity numbers.  The gist of the conversation was whether or not it was important or useful to regularly run these metrics on your code.  My coworker's point, which I *mostly* agree with, is that he would refactor a class well before it got to a high CC number by simple inspection.  As in, he doesn't need a tool to "know" when a class is getting too big or taking on too many responsibilities. 

I would agree completely (and I think you should be able to spot bad code visually anyway), except for the old parable about putting a frog in boiling water.  If you drop a frog into boiling water he jumps right out.  If you put a frog in cool water, then gradually heat the water to boiling, he won't jump out.  Classes can be the same way as they slowly accrete yet one more function.  A CC number is an awfully quick warning that you're going out of bounds.  A run of NDepends onto StructureMap pretty well confirmed to me some weak spots in the class structure and spurred me to make some refactorings that cleaned up the internal structure.

Frank Kelly has a post that pretty well expresses my opinions on metrics.  But in brief, even though I routine forget to run NDepends, I think:

  • Metrics should only inform, never take the place of a constant attention to code structure and visual awareness of that structure
  • Metrics are very useful when you inherit someone else's codebase

– btw, this post and conversation was spawned by a codebase I was looking at (no names) that had some monster classes.  When I ran some CC numbers I came up with a half dozen classes over 200 in Cyclomatic Complexity.  20 is the rule of thumb for the upper threshold of a class, just in case you're not familiar with the CC number.  200 screams for refactoring.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • feelys2010

    Thank you for sharing, hoping to see more of your articles.
    fiber optic rotary joint http://www.electricslipring.com/

  • http://www.gesundheitshersteller.de Annerose

    These comments have been invaluable to me as is this whole site. I thank you for your comment.

  • Eric McVicker

    I’ve been wondering if I could use metrics such as CC to “sell” refactoring some. Seems like having some numbers to back a reason to change some code would appeal to some managers who are not engineers. It sounds better when you present some numbers that you can say are linked to code stability, performance, reuse or maintenance rather than “I changed the code because it is better this way”.

  • http://virtualgenius.spaces.live.com Paul Rayner

    Reminds me of something my Mathematics professor used to say in my stats class:

    “Statistics should be used like a drunk uses a lamp post, for illumination and support”

  • http://www.codebetter.com/blogs/raymond.lewallen rlewallen

    Brian, yeah the CC number right there next to the method is nice to have so you can always see it. I wish it had more metrics available, but for on-the-fly stuff, it would really slow stuff down if you incorporated more metrics. Also, a lot of metrics requred an evaluation of the entire solution, especially at the assembly level, hence the reason DxCore only supplies method level metrics.

  • Brian Schmitt

    Not sure if you have checked it out, but there is a free Metrics Plugin for the DXCore (Coderush) that will display the metrics for a routine next to it. It also now ships with Coderush if you have it installed. It does it only for the Method level and not an entire class, but it will give you a quick idea of any trouble spots…

  • http://www.codebetter.com/blogs/raymond.lewallen rlewallen

    500 million? Is that even possible? I couldn’t do that if I tried.

    I actualy use metrics quite often, specifially the CC you talked about. Other metrics I use often are coupling, abstractness and stability. While usually this types of metrics are easy enough to eyeball and notice just by looking at the code, I like to keep the metrics at hand just so I can look over them. This is why NDepend is part of CI process on each build.

    A little bit I wrote on using and applying those metrics I mentioned is here: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/15/129265.aspx

  • jeremiah johnson

    i have some code that was written by some non-OO people with cyclomatic complexities of 500 million +.

    over 500 million unique paths through a method. the response i get from them is “What’s the problem, i do that in PHP all the time.”