1. Introduction

In this tutorial, we’ll explain how to calculate the cyclomatic complexity of a software module.

According to the rational asset analyzer software documentation, cyclomatic complexity is a measurement of the stability and confidence of a software module. The higher the cyclomatic complexity of a software module, the more defects it has. Therefore, it is recommended that a complex software module is split into smaller modules.

2. Problem Description

Let M be a software module. The cyclomatic complexity of M is the number of linearly independent paths through M.

For example, let’s say we have the following module (in pseudocode):

Rendered by QuickLaTeX.com

The number of linearly independent paths is two.

The higher the cyclomatic complexity of a software module, the more complex it is. A use case for this is in software development. Software developers are always designing modules, and it’s important for them to know whether the module is complex.

3. Cyclomatic Complexity

Cyclomatic complexity was developed by Thomas J. McCabe in 1976.

A control flow graph (CFG) is an abstract representation of a software module. Each node (in the CFG) represents a single block of code, with statements without any jumps. Each directed edge (in the CFG) represents a jump between nodes. A linearly independent path of a software module is a path from the entry to the exit node of the module’s CFG:

Switch Control Graph

The number of linearly independent paths in the CFG above is three.

There are two known methods for calculating the cyclomatic complexity of a software module.

3.1. Method 1

Given an input module M, we compute its corresponding CFG C. Then we count the number of nodes n, the number of edges e, and the number of connected components c in C. The cyclomatic complexity value is equal to en + 2c.

3.2. Method 2

McCabe showed that the cyclomatic complexity of a software module is equal to one plus the number of decision statements in the software module. According to McCabe, decision statements can be:

  • Loop statements (i.e., D0, DO-WHILE)
  • The CASE alternatives in a SWITCH statement (the default/ the else case is excluded)
  • Each logical operator in an IF statement

In a CFG, a decision node corresponds to a decision statement.

Given an input module M, we compute its corresponding CFG C. Then we count the number of decision nodes in C and add one to the value.

The number of nodes in the CFG of a software module with no decision statements is one. Hence, the cyclomatic complexity is zero.

4. Example

Let’s work out an example from a lecture on cyclomatic complexity:

Rendered by QuickLaTeX.com

First, we compute its corresponding CFG:

Control Flow Graph

4.1. Method 1

We count the number of edges, the number of nodes, and the number of connected components in the CFG.

Finally, we compute the cyclomatic complexity, which is 7 – 6 + 2(1) = 3. This means that there are three linearly independent paths in the module. These are highlighted in blue in the figure below:

Linearly Independent Paths

 

4.2. Method 2

We count the number of decision nodes (or decision statements in the corresponding software module). The x < 10 and x > 5 nodes are decision nodes. Therefore, the number of decision nodes in the CFG is two. The cyclomatic complexity is equal to the number of decision nodes plus one, which is three.

5. Complexity

The depth-first search (DFS) algorithm traverses the given CFG to count the number of nodes (or decision nodes), edges, and connected components.

Let N be the number of nodes and E be the number of edges (in the given CFG).  If the CFG is represented by an adjacency list, then the DFS algorithm will take O(V+E) time.

6. Conclusion

In this article, we showed how to calculate the cyclomatic complexity of a software module using two different methods. The two cyclomatic complexity methods depend on the CFG of the given software module.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.