Cyclomatic Complexity

Much of my day is spent convincing engineers that there are simpler ways of implementing their designs. Much of the rest is convincing executives and managers that what they want isn't simple at all.

Invariably some little hot-head tries to argue with me that implementing a general case is more complicated than a special optimized case. If the punk in question has cracked a book they'll likely bring up some metric like Cyclomatic Complexity.

Thomas McCabe socialized this metric in the 70's as a mechanism for predicting where code would have future maintain problems. It's often thrown into the blender when people are trying to construct qualitative measures for code quality. Here's the formal equation:

CC = E - N + P

E = number of edges N = number of nodes P = number of connections or exits

It can be hard to see how equations like this apply to code so let me say it a different way: Cyclomatic Complexity represents the number of code paths through a section code.

How do you count the code paths? Start with one for the entry into the code, and add one more for every decision point. Decision points are the control of flow statements like If…Then…Else or Switch. The CC for the following snippet is three (3).

public int adjustRange( int rangePrimary ) {
bool adjustedValue = 42;
if ( rangePrimary == 6 ) {
adjustedValue = 42;
} else {
adjustedValue = 9;
}
return adjustedValue;
}

This example was really simple but is illustrative of how the CC may be calculated.

So how complex is complex? As with most metrics, the interpretation is very subjective. Since the higher the number, the more complex the code, it stands to reason that code with higher numbers would be more prone to issues. Perhaps bugs because of the logic convolutions, or issues with maintenance because of the number of things impacted by even simple changes. In a sweeping generalization I can say that for my reviews, code with values higher than 20 would be suspect, and higher than 30 would likely not pass.

The important thing is to realize it isn't a measure of quality, just an indicator where better organization or testing might be advisable. Personally, I tend to gauge an engineers competence inversely to the CCs of the code they routinely produce. In my experience, engineers who write better code routinely produce code with low CCs and vice versa.