An In-Depth Explanation of Code Complexity

It’s no secret code is a complicated thing to write, debug, and maintain. This is a well-established fact. Moreover, the more complex the code, the higher the level of code defects, making the code costlier to maintain.

So, by reducing 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.

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

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.

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.

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 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.

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, then try out Codacy. It’s free for 30 days.

Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.