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 , 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 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.
- 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.