Blog post

Discussing Cyclomatic Complexity

Olivier Gaudin photo

Olivier Gaudin

CEO & Co-founder

Date

Bad code doesn’t just disappear and the consequences of overlooking it can be costly. 

Googling on Cyclomatic Complexity (CC), gives some interesting results... Among those results, you'll find the two following definitions :

  • A measure of the complexity of a software module, equal to e - n + 2, where e is the number of edges in the control flow graph and n is the number of nodes in this graph (that is, the cyclomatic number of the graph plus one)
  • A measurement of the intricacy of a program module based on the number of repetitive cycles or loops that are made in the program logic. It is used as a general measure of complexity for software quality control as well as to determine the number of testing procedures
  • ...

Those two definitions, though perfectly true, are one of the reason for Sonar to exist: going away from the fact that code source quality is a notion only accessible to elite. Sonar is about democratization of the source code quality concepts to be understandable and usable by every stakeholder in a development project.

Having said that, what is it that CC is trying to represent? This is roughly the number of different paths in your source code and there are two ways in java to begin a new path : 

  • Calling a method (CC + 1)
  • Encountering the following keywords : if, while, repeat, for, &&, ||, catch, case, etc ... (CC + 1)

The good news is that calculating the cyclomatic complexity is a human accessible operation. Moreover, according to the previous definition it's easy to understand that the more paths you have in your application, the more complex your application will be.

But does that mean a program with a high cyclomatic complexity has a poor quality ? For sure not ! Otherwise all developers would prevent themselves from doing anything beyond a simple "HelloWorld" program whose cyclomatic complexity is 1 and would quickly lose their jobs :-) 

Having a high total cyclomatic complexity on a program just means that a lot of logic has been implemented in the program but you cannot deduce any quality information from there. When zooming on classes or methods, that's another story. 

Is it better to have a method with a CC of 30, or three methods with a CC of 10 each ? If you have been in charge of source code maintenance for an application written by somebody else, you know the answer : when having three methods with a CC of 10 each, the chance is higher that the program is more maintainable, with a better separation of logic. As a consequence, you also decrease the risk to inject a bug. The CC value by method can be used to evaluate the quality of the source code.

At the class level, you can follow the same logic : high CC by class could be the witness of bad levels of decoupling, encapsulation and cohesion. 

In fact, what matters in a program is not its total cyclomatic complexity but the fact that each of its methods / classes has a suitable low level of CC

We'll discuss in an other post how valuable Sonar can be to help identify those non suitable parts of source code.