Sw Design Metrics: Cyclomatic Complexity

The cyclomatic complexity metric is a measure of the quality of a software design and also an indicator of the level of testability and maintainability of a program.

Cyclomatic complexity measurement was introduced by McCabe in 1976 and it indicates the number of regions in a graph. In the software world, it is the number of linearly independent paths that comprise the program. To determine the paths, the program procedure is represented as a strongly connected graph with unique entry and exit points.

The formula for computing the cyclomatic complexity is: M=V(G)=e-n+2p, where:

V(G) = cyclomatic number of G,

e = number of edges,

n = number of nodes,

p = number of unconnected parts of the graph

If this calculus seems too complicated:

Start with 1 for a straight path through the routine.

Add 1 for each of the following keywords or their equivalent: if, while, repeat, for, and, or.

Add 1 for each case in a switch statement.

Example Let’s consider graph represented in the picture, which can be seen as a simple function with two if statements:

As we can see, the cyclomatic complexity is a summary index of binary decisions.

The cyclomatic complexity metric is additive: the complexity of several graphs considered as a group is equal to the sum of the individual graphs' complexities. It ignores the complexity of sequential statements and it doesn’t distinguish different kinds of control flow complexity such as loops versus IF-THEN-ELSE statements or cases versus nested IF-THEN-ELSE statements.

The cyclomatic complexity is applicable both in the OOP and Non-OOP. To have good testability and maintainability, McCabe recommends that no program module should exceed a cyclomatic complexity of 10. Of course, it can vary between some limits based on different factors (application type, programming language, etc).

The SEI provides the following basic risk assessment based on the value of code:

Cyclomatic Complexity	Risk Evaluation
1 to 10	a simple program, without very much risk
11 to 20	a more complex program, moderate risk
21 to 50	a complex, high risk program
> 50	an un-testable program (very high risk)

1 to 10	a simple program, without very much risk
11 to 20	a more complex program, moderate risk
21 to 50	a complex, high risk program
> 50	an un-testable program (very high risk)

1 to 10 a simple program, without very much risk
11 to 20 a more complex program, moderate risk
21 to 50 a complex, high risk program
> 50 an un-testable program (very high risk)

Measuring the cyclomatic complexity is important as it is correlated with the code coverage and the test effort.

In order to obtain this metric it is enough to run almost any static code analysis tool.

In the object oriented programming, a set of six metrics was proposed in 1994 by Chidamber and Kemerer, based on the cyclomatic complexity, which later became the commonly referred to CK metrics suite:

Weighted Methods per Class (WMC): the sum of the complexities of the methods (complexity is measured by cyclomatic complexity).

Depth of Inheritance Tree (DIT): the length of the maximum path of a class hierarchy from the node to the root of the inheritance tree.

Number of Children of a Class (NOC): the number of immediate successors (subclasses) of a class in the hierarchy.

Coupling Between Object Classes (CBO): the number of classes to which a given class is coupled (a class is coupled to another one if it invokes another one's member functions or instance variables ).

Response for a Class (RFC): the number of local methods plus the number of methods called by local methods.

Lack of Cohesion on Methods (LCOM): The cohesion of a class is indicated by how closely the local methods are related to the local instance variables in the class. LCOM is measured as the number of disjoint sets of local methods. Lack of cohesion increases complexity and opportunities for error during the development process.