It’s no secret code is a complicated thing to write, debug, and maintain which is necessary for high software quality. Moreover, high code complexity brings with it a higher level of code defects, making the code costlier to maintain.
So, by reducing code complexity, we can reduce the number of bugs and defects, along with its lifetime cost. What exactly is complex code? How can we objectively assess how complex a piece of code is, whether that’s an entire codebase or one small function?
In this article, I’m going to walk through three complexity metrics for assessing code complexity. These are:
- Cyclomatic complexity
- Switch statement and logic condition complexity
- Developer skill
I’ll also go through some of the benefits of assessing and understanding code complexity.
Cyclomatic Complexity
In 1976, Thomas McCabe Snr proposed a metric for calculating code complexity, called Cyclomatic Complexity. It’s defined as:
A Quantitative Measure Of The Number Of Linearly Independent Paths Through A Program’s Source Code…Computed Using The Control Flow Graph Of The Program.
If you’re not familiar with a Control Flow Graph:
It Is A Representation, Using Graph Notation, Of All Paths That Might Be Traversed Through A Program During Its Execution.
Said more straightforwardly, the fewer the paths through a piece of code, and the less complex those paths are, the lower the Cyclomatic Complexity. As a result, the code is less complicated. To demonstrate the metric, let’s use three, somewhat arbitrary, Go code examples.
Example One
func main() {
fmt.Println("1 + 1 =", 1+1)
}
As there’s only one path through the function, it has a Cyclomatic Complexity score of 1, which we can find by running gocyclo on it.
Example Two
func main() {
year, month, day := time.Now().Date()
if month == time.November && day == 10 && year == 2018 {
fmt.Println("Happy Go day!")
} else {
fmt.Println("The current month is", month)
}
}
In this example, we’re retrieving the current year, month, and day. With this information, we then check if the current date is the 10th of November 2018 with an if/else condition.
If it is, then the code prints “Happy Go day!” to the console. If it isn’t, then it prints “The current month is” and the name of the current month. The code example is made more complicated as the if the condition is composed of three sub-conditions. Given that, it has a higher complexity score of 4.
Example Three
func main() {
_, month, _ := time.Now().Date()
switch month {
case time.January:
fmt.Println("The current month is January.")
case time.February:
fmt.Println("The current month is February.")
case time.March:
fmt.Println("The current month is March.")
case time.April:
fmt.Println("The current month is April.")
case time.May:
fmt.Println("The current month is May.")
default:
fmt.Println("The current month is unknown.")
}
}
In this example, we’re printing out the current month, based on the value of month, retrieved from the call to time.Now().Date(). There are seven paths through the function, one for each of the case statements and one for the default.
As a result, its Cyclomatic Complexity is 7. If we’d accounted for all the months of the year, along with a default, however, its score would be fourteen. That happens because Gocyclo uses the following calculation rules:
1 is the base complexity of a function +1 for each ‘if’, ‘for’, ‘case’, ‘&&’ or ‘||’
Using these three examples, we can see that by having a standard metric for calculating code complexity, we can quickly assess how complex a piece of code is.
We can also see how different complex sections of code are in comparison with each other. However, Cyclomatic Complexity is not enough on its own.
Switch Statement and Logic Condition Complexity
The next assessor of code complexity is the switch statement and logic condition complexity. In the code example below, I’ve taken the second Go example and split the compound if condition into three nested conditions; one for each of the original conditions.
func main() {
year, month, day := time.Now().Date()
output := fmt.Sprintf("The current month is %s", month)
if month == time.November {
if day == 13 {
if year == 2018 {
output = fmt.Sprintf("Happy Go day!")
}
}
}
fmt.Println(output)
}
Which is easier to understand (or less complicated), the original one, or this one? Now let’s build on this, by considering the following three questions.
- What if we had, as we do above, multiple if conditions and each one was quite complex?
- What if we had multiple if conditions and the code in the body of each one were quite complex?
- Would the code be easier or harder to understand?
It is fair to say that the greater the number of nested conditions and the higher the level of complexity within those conditions, the higher the complexity of the code.
Software Developer Skill Level
What about the skill level of the developer? Have a look at the C version of the second Go example below.
#include <stdio.h>
#include <time.h>
#include <string.h>
int main()
{
time_t t = time(NULL);
struct tm tm = *localtime(&t);
const char * months[12] = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"};
if (tm.tm_year == 2018 &&
strncmp(months[tm.tm_mon], "November", strlen(months[tm.tm_mon])) == 0
&& tm.tm_mday == 10)
{
printf("Happy C Day!.\n");
} else {
printf("The current month is %s.\n", months[tm.tm_mon]);
}
}
Technically, it does what the other examples do. However, it requires more code to achieve the same outcome. To be fair, if I had a greater familiarity with C, the code might be no longer than the Go example.
However, let’s say this is the minimum required to achieve the same outcome. If you compare the two, given the more verbose nature of C’s syntax when compared to Go, it’s harder to understand.
What’s more, if you had no prior experience with C, despite a comparatively similar Cyclomatic Complexity score, what would your perception be?
Would you consider the code to be less or more complicated? So this is another essential factor in understanding code complexity.
The Benefits of Measuring Software Complexity
There are four core benefits of measuring code complexity, plus one extra.
Better Tests
By knowing how many independent paths there are through a piece of code, we know how many paths there are to test.
I’m not advocating for 100% code coverage by the way—that’s often a meaningless software metric. However, I always advocate for as high a level of code coverage as is both practical and possible.
So, by knowing how many code paths there are, we can know how many paths we have to test. As a result, you have a measure of how many tests are required, at a minimum, to ensure that the code’s covered.
Reduced Risk
As the old saying goes:
It’s Harder To Read Code Than To Write It.
What’s more:
- Code is read far more than it is written
- A good software developer should never be assessed by the lines of code they’ve written (or changed), but by the quality of the code they’ve maintained.
Given that, by reducing code complexity, you reduce the risk of introducing defects; whether they’re small or large, slightly embarrassing or bankruptcy-inducing.
Lower Costs
When the risk of potential defects is reduced, there are fewer defects to find—and remove. As a result, the maintenance cost also reduces.
We’ve all seen and are familiar with the costs associated with finding defects at the various stages in a software’s life, as exemplified in the chart below.
So it makes sense that, if we understand the complexity of our code, and which sections are more complicated than others, then we are in a far better position to reduce said complexity.
So by reducing that complexity, we reduce the likelihood of introducing defects. That flows into all stages of a software’s life.
Greater Predictability
By reducing software complexity, we can develop with greater predictability. What I mean by that is we’re better able to say—with confidence—how long a section of code takes to complete. By knowing this, we’re better able to predict how long a release takes to ship.
Based on this knowledge the business or organization is better able to set its goals and expectations, especially ones that are directly dependent on said software. When this happens, it’s easier to set realistic budgets, forecasts, and so on.
Helps Developers Learn
Helping developers learn and grow is the final benefit of understanding why their code is considered complex. The tools I’ve used to assess complexity up until this point don’t do that.
What they do is provide an overall or granular complexity score. However, a comprehensive code complexity tool, such as Codacy, does.
In the screenshot above, we can see that, of the six files listed, one has a complexity of 30, a score usually considered quite high.
Cyclomatic complexity is a great indicator to understand if code quality deteriorating for any given change. Cyclomatic complexity can be harder to reason when looking at it or comparing whole modules given its infinite scale and not being related to the module size. However, something that you might find useful is looking at Codacy’s File list sorted by priority, which will help you understand which files are candidates of poor code quality, and then by consequence their modules.
That’s a Wrap
Also, this has been an in-depth discussion about what code complexity is, how it’s assessed, as well as the significant benefits of reducing it. While there is more to understanding code complexity than I’ve covered here, we’ve gone a long way to understanding it.
If this is your first time hearing about the term or learning about any of the tools, I encourage you to explore the linked articles and tools, so that you learn more. If you don’t code in Go or C, then google “code complexity tool” plus your software language(s). You’re sure to find many tools available.
Finally, if you want a comprehensive tool for assessing code quality, and one that helps your developers learn and grow, type on Google automated code reviews and you'll find a few tools worth testing, among them, is Codacy.