Home Developer An In-Depth Explanation of Code Complexity

An In-Depth Explanation of Code Complexity




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.")
        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!")


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:

  1. Code is read far more than it is written
  2. 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.

Rising cost of defects

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.

File complexity list

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.

For more tips to improve code quality check out some other blog posts from Codacy.

Finally, if you want a comprehensive tool for assessing code quality, and one that helps your developers learn and grow, then try out Codacy.

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.



  1. I really enjoyed your article. I found it useful as I was thinking through some issues related to code complexity. However, I think there is a significantly less complicated solution in C. One deficiency of C is the lack of easily accessible month-words in the standard library, so the lookup of for the month-word string is unavoidable. However, you can make the date comparison for C-Day with far less work by comparing two time values. I’ve provided an implementation below.


    • Hi Hans, thank you for reachint out. The post on dzone is the exact copy from this article, which dzone does not allow any branding or mention of the company who writes it but I’d like to confirm with you that this is the original article. Thank you!

  2. Hello, really informative article.
    I am a little confused on “Example Three”, as there is 5 cases and a default case in the code. But the describtion is counting them as 7.

    So is there 6 or 7 cases?
    And is that then also the complexity just for the paths of the switch case?
    Or am I way off?

    • 1 is the base complexity of a function – this is stated in this article.

      each case adds 1, i think we get to 6 because the ‘default’
      case of the switch statement is also a case.

      so 6 + 1 = 7

    • The base complexity score of a function is 1, as stated in this article

      So adding the 5 cases and the default we get 7


Please enter your comment!
Please enter your name here

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

22 software development trends for 2022

What does next year have in store for the ever-evolving software world? Here are our 22 software development trends for 2022

Code quality beyond bug fixing: we did a live product AMA 🎙

On November 16th, we did our first live product AMA, called Code quality beyond code fixing. In case you are wondering,...

Organization Coding Standards: Beta version is now live!

You spoke; we listened! We’re excited to announce that admins can now set organization coding standards in Codacy! 🎉 With this...

Web Summit 2021: Lessons of changing culture for product-led growth

We share lessons learned while changing our culture to support product-led growth, and we offer tips on how you could avoid the same mistakes.

How LOGEX uses Codacy for ISO/IEC 27001:2013 compliance

We spoke with Tim van Loosbroek, Head of Infrastructure and Security at LOGEX, about how Codacy helps them comply with ISO/IEC...