Wander the halls of an enterprise software outfit looking to improve, and you’ll hear certain things. First and foremost, you’ll probably hear about unit test coverage. But, beyond that, you’ll hear discussion of a smattering of other metrics, including cyclomatic complexity.
It’s actually sort of funny. I mean, I understand why this happens, but hearing middle managers say “test coverage” and “cyclomatic complexity” has the same jarring effect as hearing developers spout business-meeting-speak. It’s just not what you’d naturally expect.
And you wouldn’t expect it for good reason. As I’ve argued in the past, code coverage shouldn’t be a management concern. Nor should cyclomatic complexity. These are shop-heavy specifics about particular code properties. If management needs to micromanage at this level of granularity, you have a systemic problem. You should worry about these properties of your code so that no one else has to.
With that in mind, I’d like to focus specifically on cyclomatic complexity today. You’ve probably heard this term before. You may even be able to rattle off a definition. But let’s take a look in great detail to avoid misconceptions and clear up any hazy areas.
Defining Cyclomatic Complexity
First of all, let’s get a specific working definition. This is actually surprisingly difficult because not all sources agree on the exact method for computing it.
How can that be? Well, the term was dreamed up by a man named Thomas McCabe back in 1976. He wanted a way to measure “the number of linearly independent paths through a program’s source code.” But beyond that, he didn’t specify the mechanics exactly, leaving that instead to implementers of the metric.
He did, however, give it an intimidating-sounding name. I mean, complexity makes sense, but what does “cyclomatic” mean, exactly? Well, “cyclomatic number” serves as an alias for something more commonly called circuit rank. Circuit rank measures the number of independent cycles within a cyclic graph. So I suppose he coined the neologism “cyclomatic complexity” by borrowing a relatively obscure discrete math concept for path independence and applying it to code complexity.
Well then. Now we have cyclomatic complexity, demystified as a term. Let’s get our hands dirty with examples and implications.