Code Quality – Why Avoid Higher Cyclomatic Complexity?

This article represents my thoughts on why one should avoid a higher cyclomatic complexity (value more than 15 or so). Recently, I have been doing code reviews for multiple projects using Sonar. This is where I came across the rule called as “Cyclomatic Complexity”. The rule raises an alert for all the methods whose cyclomatic complexity is found to be more than 10. Thus, I thought of listing down reasons why one should pay attention to the cyclomatic complexity of method when he/she is writing fresh method or making changes to existing method. Personally, I do agree and strongly believe that one should avoid writing methods/function of code complexity higher than 15 or so.  Please feel free to comment/suggest if I missed to mention one or more important points. Also, sorry for the typos.

Before we look at some of the reasons, lets try and understand, in brief, some of the following:

• What is Cyclomatic Complexity?: As per the Wikipedia page on cyclomatic complexity, Cyclomatic complexity is a software metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to indicate the complexity of a program. It is a quantitative measure of the complexity of programming instructions. It directly measures the number of linearly independent paths through a program’s source code. Simply speaking, cyclomatic complexity determines number of decision points in one’s code. Decision points could be if-then-else, switch-case, do-while, for, while, ||, && etc.
• How to measure cyclomatic complexity?: The way to measure cyclomatic complexity (CC) is to measure number of decision points such as if-then-else, switch-case, do-while, for, while, ||, && etc, and add 1. An empty method such as following has cyclomatic complexity of 1.

  void foo(){
  	
  }
  

  The method such as following has CC of 2 (1 for if + 1) .

  void foo() {
    if( i < 10 ) {
  
    }
  }
  

  The method such as following has CC of 3 (1 for if, 1 for && + 1)

  void foo() {
    if( i < 10  && i%2 != 0 ) {
  
    }
  }
  

  The method such as following has CC of 4 (1 for if, 1 for && + 1) .

  void foo() {
    if( i < 10  && i%2 != 0 ) {
      for( int j = 0; j < i; j++ ) {
      }
    }
  }
  

• What is appropriate Cyclomatic Complexity value?: Well, to achieve high code coverage, one may want to limit the CC to a value upto 15 or so. Anything more than should be asked for code review and if possible, recommended for refactoring.

Following are some of the key reasons why one would want to avoid higher cyclomatic complexity:

• Difficult to test: A code with higher cyclomatic complexity would become difficult to unit test, or in other words, achieve high code coverage. Thus, it is more so recommended to limit the CC to 10 or so such that one could achieve high code coverage. This does impact the maintainability aspect of code which is one of the key trait of software quality. Higher the cyclomatic complexity, difficult is it to achieve higher code coverage, and thus, lower becomes the code maintainability.
• Difficult to read & understand: A code with higher CC would be difficult to read. Imagine a method/function with lot of if-then-else conditions along with for/while loops. This impacts the usability aspect of code quality. Higher is the code complexity, lower the code usability.
• Propagates code hacks and hence, fragility: A code with higher CC propagates hacks, primarily, because it makes it difficult for the developers to refactor the code to put their changes/fix primarily due to the reason that they do not have knowledge around associated business logic/rules & different possible test cases. Thus, developers tend to tweak the code and thus, introduce hack to fix the problem at hand.
• Prevents change in design: A code with higher cyclomatic complexity tends to have so many business roles/logic included within one method. This makes it difficult to refactor the code to align it with newer design.
• Difficult to re-factor: As the cyclomatic complexity of the code increases, it becomes difficult to refactor the code.