Strides Interactive

Cyclomatic Complexity - How can I use it?Filed Under: Weekly Tuesday Dose of goodness

Hi all,

Let’s fall back a little and talk about MCC (McCabe’s Cyclomatic Complexity) once more shall we? In my previous article regarding this metric, I’ve mentioned that MCC should only serve as a guide, not as a rule.

However, I’ll like to correct my statement.

MCC is a guide yes, but it serves more than just a guide for a certain measurement. How so?

Read on…

Introduction

Now we’ve known what’s MCC, let’s just skip the whole thing about how it works completely shall we? For the benefit of those who doesn’t know what’s MCC, please take a look at the following link:

http://www.stridesdev.org/2009/11/cyclomatic-complexity-is-it-a-rule-or-a-guide/

So, how does MCC help us in our daily lives? First, we need to understand the culture about around us. As we know, especially in the US, software quality has been a major concern to most if not all software houses. Although the notion of quality is gradually being appreciated in Asia, most people are still resistant towards how much time they should devote to the quality of their software.

To add, there’re 2 ways to count MCC. In our previous post, I’ve only mentioned the newer method, that counts all internal conditions as individual counts.

Review on counting methods:

Take this for example:

if( a < 0 || b > 2  && c == 5 && d == 6)
{
}

For the method I’ve introduced previously, the MCC count would be 1 + 4 = 5.
For the older method, MCC count would be 1 + 1  = 2.

The entire if() is counted as a single hit.

Reason being that in order to cover the positive branch, it only takes 1 instance out of the many possibilities (especially the ones with || operators) to trigger. The same goes for the negative branch.

Therefore, this older method is still very useful for unit testing in terms of decision coverage.

The newer method may trigger a lot more MCC hits, but it’s index is indicative of how many tests you need to hit MC/DC coverage. (Modified Condition/Decision Coverage)

This is crucial to applications that are not supposed to fail at all. For example, medical life support devices, aerospace software and so on…

Appreciation for MCC

Therefore, MCC actually helps a tester or developer come up with a test plan on how many test cases they’re supposed to generate in order to fulfill a certain test objective.

Since there’s a guideline for the developer and if this guideline is enforced by the management, the developer will gradually adopt a development style that will yield a lesser MCC count per method, thus naturally transforming codes into a more modular and organized state.

Imagine a method having 30 MCC - the tester/developer would have to developer an additional 30 test cases in order to supposedly test the method. The intricate logic in between the codes will cause staging to be a logistic nightmare. (Staging means the amount of effort required to stage and setup a test case)

Conclusion

In conclusion, MCC is not just a guide to a metric, it’s also a guide as to how many test cases you’ll have to write in order to fulfill your test objectives.

Be in the first or second method, both methods have their merits in indicating how many tests should be written.

This gives the developer and their management a clearer picture on the amount of work that needs to be done, allowing managers to schedule time for a more deterministic test plan.

All in all, I believe, in my humble opinion, that adopting to MCC alone can surely and gradually improve code organization and test plans.

To be fair though, code organization doesn’t always necessarily mean code quality even though the former can weed out quite a bit of careless mistakes.

Hopefully this article is informative for you. I’ll be going for reservist for the next 2 weeks and therefore will not be posting till 16th of March. Need to go serve my nation!!

Therefore, take care! Happy Lunar New Year once more! Gong Xi Fa Cai!

Signing off,
Jeremy