How to Measure Code Complexity?
In this blog post, I want to explain what cyclomatic complexity is, how you can, and why you should use it in your program.
Cyclomatic Complexity
The invention of cyclomatic complexity dates back to 1976. Back then Thomas McCabe was looking for an easy and empirical metric to measure the level of complexity of a structured program. To accomplish this he uses formulas and theorems of graph theory. To keep it simple I won't go too deeply into the maths behind it, if it’s interesting for you, you can check out the sources at the end of the article.
Measuring the Cyclomatic Complexity
Let’s get started on how you can calculate the cyclomatic complexity then. There are two ways to do so. I will explain the graphical one first.
1. Using the Control Flow Graph
McCabe defines the cyclomatic complexity as M = e — n + 2p. Where M is the cyclomatic complexity of a structured program, e is the number of edges in the control flow graph, n is the number of nodes and p is the number of connected components. The formula works on the premise that the program has a single start and a single endpoint. When we look at a single function or method the number of connected components is always one. So in that case we can simplify the method like so:
M = e — n + 2p = e — n + 2(1) = e — n + 2
This means that we can calculate the cyclomatic complexity by simply subtracting the number of nodes from the number of edges and adding two.
For example given the following function:
function isEven(number){
var result;
if(number % 2 === 0){
result = true;
} else {
result = false;
}
return result;
}The control flow graph of the function looks like this:
Now you can count the number of edges e, and the number of nodes n and put them into the formula M = e — n + 2 so you get M = 5–5 + 2 = 2. That means the cyclomatic complexity of this function is 2.
We can simplify this even further by using Euler’s formula n — e + r = 2, where r represents the number of regions in a control flow graph. When we just change the order of the terms we get r = e — n + 2 which equals our formula r = e — n + 2 = M. So we can say that the number of regions created by the control flow graph equals the cyclomatic complexity.
When we look at the control flow graph again we can easily see that there is only one region. Right? No! There are two regions one enclosed by the edges of the if statement and one outer region. Also, keep in mind that this only works on the premise that the control flow graph has a single entry and a single exit point, as I stated earlier.
2. Counting Decision Statements
The other way to ‘calculate’ the cyclomatic complexity is to start with one for the default path and add one for every decision statement such as if, for, while, do-while, and each case in a switch block. Depending on the programming language there can be more decision statements.
In the example from before you start with 1 and add 1 for the if statement. So you get the cyclomatic complexity of 2 again.
Why should you use cyclomatic complexity?
Cyclomatic complexity is a simple way to give you an objective indicator of how complex a piece of code is. There are a lot of tools that implement this metric so you can automate it and use it as a base of discussion in code reviews. I would recommend defining a maximum cyclomatic complexity with your team. Many software engineers and authors recommend a maximum of 10 or 7. I like my functions short and clear so I opt for 7, but the most important thing is to have a rule at all.
Keep in mind that cyclomatic complexity does not perfectly represent how a programmer perceives the complexity of a piece of code. Even a method with a cyclomatic complexity of one can be complex if it is a thousand lines long and a switch block with 10 cases might not be as complex as the metric would suggest.
