Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-151

Cyclomatic Complexity should be computed as defined by Thomas J. McCabe



    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:


      The Problem

      The way the Cyclomatic Complexity rule currently computes the value incorrectly in all language plugins; the rules combine computation of the Cyclomatic Complexity and Essential Complexity.

      As defined in the two following documents [1][2], the computation formula should be either (same result) :

      • CC = E − N + 2P where
        • E = the number of edges of the graph.
        • N = the number of nodes of the graph.
        • P = the number of connected components.
      • or for each method/function definition: number of conditional branches + 1 which means sum('if', 'for', '&&', '||', ternary operator, 'while', 'for', 'case') + 1
        • Lambdas should be considered as an entry point

      However, currently unconditional branches like 'return', 'break', 'continue', ... are also incrementing the value.

      The Fix

      The goal of this MMF should not be to fix the known limitations of the "Cyclomatic Complexity" measure, but to stick as much as possible to the theorical definition, so:

      • The exception handling mechanisms in modern languages like java, C#, C++, ... should not be taken into account while computing Cyclomatic Complexity. This means for example that in Java that the 'catch' and 'throw' statements should be ignored.
      • Cyclomatic Complexity must be computed on every method even if some methods can be considered as accessors in some languages (relates to SONAR-5224, SONARJAVA-398, ...).
      • In the case of switch statements, the Cyclomatic Complexity can indeed be very high, and therefore perceived by developers as a kind of FP
      • In the case of deeply nested control flow statements, the Cyclomatic Complexity can be pretty low versus the complexity perceived by developers
      • There is a strong correlation between Cyclomatic Complexity and LoC.

      The Details

      • In each language the implementation of the Cyclomatic Complexity rule(s) should be corrected to adhere to the definition of Cyclomatic Complexity. That is, increments for return, break, continue, and so on should be removed.
      • In languages with static initializers, such an initializers complexity score should be added to the class complexity score.
      • Because the Cyclomatic Complexity of a class or application largely corresponds to LoC, those metrics aren't helpful, and should be deprecated/hidden.

      [1] - http://www.mccabe.com/pdf/mccabe-nist235r.pdf
      [2] - https://en.wikipedia.org/wiki/Cyclomatic_complexity


          Issue Links



              Unassigned Unassigned
              fabrice.bellingard Fabrice Bellingard
              0 Vote for this issue
              9 Start watching this issue