The cyclomatic complexity (CC) is one of the metrics which are very very old, but it still can have a big influence for development projects. I say “can” because I know that in the past not many developers and architects look after this metric.
First a short introduction, what is CC and what is CC2 – which are the two in CodeInspector (CI).
“The cyclomatic complexity measures the complexity of a program and is based on the control flow graph. It is a count for the number of linearly independent paths through the source code.” (From the help of CI).
Ok, the CC goes through a coding block and counts every time, the control flow has a new path at a specific decision point. A new path will be created due to a “IF”, “ELSE”, “CASE” and so on.
The CC2 based on the CC and just adds another increment for every path, when a expression uses the operators “AND” or “OR”.
Short: The CC can be described by the following formula:
M = b + 1
With ‘b’ is the number of decision points. A coding block without decision points ( for example just APPEND in control tables, create of ranges, structures… ) will have at least M = 1.
What does a CC say?
The CC describes the complexity of a special coding block. (Ok, nice try).
Short, the CC tells you, how many test-cases you have to build, when you want to test your coding block. With this information, you have a information about how easy it is to maintain your coding block.
Finally, the CC should be between 7 and 15 at each coding block.
For my own projects or audits I use the following settings:
CC or CC2 and what about
Because the CC does not regard on operators in expressions, I use mainly the CC2. In the following, I just say CC meaning CC2.
Second, some critics say, that the CC only regards on the hard-facts never regarding the human reading.
The CASE-expression for example get’s a very high count in the CC because every WHEN-switch will be counted.
WHEN '1'. l_name = 'Monday'.
WHEN '2'. l_name = 'Tuesday'.
WHEN '3'. l_name = 'Wednesday'.
WHEN '4'. l_name = 'Thursday'.
WHEN '5'. l_name = 'Friday'.
WHEN '6'. l_name = 'Saturday'.
WHEN '7'. l_name = 'Sunday'.
For you as developer it is very easy to read, what the statement does. But for the CC metric it is very heavy, because it will increment your block through 7 points.
In CI you can disable this check, but: look at the next topic and you will see, that there is no advantage if you disable this check.
With the value of CC, you can measure and ensure the quality and stability of your software. Even the enhanceability.
1) For each value of CC you should have at least one test to ensure the correctness. E.g. use ABAPUnit and write so many tests as your CC counts.
2) Have you thought about documentation? If you want to describe what your method do, and you have a CC of 15 for example, you will need to document at least 15 different states of your method! So, reduce your CC and you will get an easier software to maintain.
3) When you a have a high CC, you should perform some refactoring with established design-patterns like factory, command, strategy, chain-of-responsibility … and you will see, how easy it is to reduce the complexity by lift up your software to a higher quality degree. For example the CASE can very easy transformed into a command or strategy pattern. Think about UI-development, where you must handle a lot of events. When you take the CASE, you have a lot of code to maintain – use a single interface and call it dynamically will reduce your area to maintain and you can enhance your application very fast and stable.
4) If you have reduced the CC, you will see, that you will have more reusable elements of your software and you can implement much easier new requirements.
5) Try to think about easier implementations or tools. For example, if you have a very complex business case with a lot of decisions and operators, you should think about to reduce your complexity by introducing BRF+ as rules engine.