Cyclomatic complexity is a code metric (integer value 1 or more) used to measure how complex a function/method is.
It does not take into account lines of code but instead considers complexity to be the distinct paths through a function.
Microsoft defines cyclomatic complexity as measuring the amount of decision logic in a source code function.
Cyclomatic complexity: if if if if if else …
Because cyclomatic complexity concerns itself with decision branches through a function it also provides us with a minimum number of unit tests we should have. So if a function has a cyclomatic complexity of 5 then we should have at least 5 unit tests against it to gain full branch coverage.
How to measure Cyclomatic Complexity
Cyclomatic Complexity is measured the following way:
- Every function starts with a value of one.
- One is then added for each control flow statement, plus one for each logical NOT, AND and OR in each condition.
In C# this means the following keywords/operators cause cyclomatic complexity to increment by one: if, while, for, foreach, case, default, continue, goto, &&, ||, catch, ternary operator (?:), null-coalescing operator (??), etc.
The following keywords would not cause cyclomatic complexity to be incremented by one: else, do, switch, try, using, throw, finally, return, etc.
Object creation, a method call or field access would also not cause an increment.
However, you certainly should not try to calculate cyclomatic complexity for methods yourself manually. See section below “Cyclomatic Complexity in Visual Studio”.
What’s too much?
A lower cyclomatic complexity value is better than a higher value, but why?
“Overly complex modules are more prone to error, are harder to understand, are harder to test, and are harder to modify.”
- Thomas McCabe (Structured Testing: A Testing Methodology Using the Cyclomatic Complexity metric)
So high cyclomatic complexity leads to code that is more error prone, hard to understand, and harder to test and change in the future. If this is the case however, realistically what should our limit be?
This certainly is an area of debate. From the book: “Code that fits in your head” Mark Seemann suggests the number should be ideally 7 or less based on Miller’s Law (AKA the “7 +- 2 rule”) because this is the average number of things a person can hold in their short term memory at one time. However, Thomas McCabe (see quote above) says cyclomatic complexity should be limited to 10 with some developers that know the code base very well allowing a limit of 15. Microsoft defines “excessive complexity” to be a cyclomatic complexity value of 25 or more (see section “Cyclomatic Complexity & Code Analysis” below).
Exceptions to high Cyclomatic Complexity
There may be some examples of where higher cyclomatic complexity might be acceptable.
- Functions that only contain a single switch statement that has many cases. In the case where refactoring the code to remove cases is too difficult this scenario may be deemed acceptable. However, the logic in each case should be minimized (e.g. a single function call in each case).
- High cyclomatic complexity could be acceptable if you have a “high functioning” (i.e. senior) team that is very familiar with the code base. Personally I find this a cop-out reason. No team stays together forever and people come and go. What happens when someone new joins the team and is unfamiliar with the code?
Reducing Cyclomatic Complexity
Cyclomatic complexity is essentially a measurement of the complexity of a function, so to lower a function’s cyclomatic complexity it must be simplified.
In essence we need to reduce the decision based logic of a function.
Some things to try:
- Refactor the function in question especially using the refactoring “Extract method”. This will lead to more functions which are each of less length and complexity. Any duplicate code in a function can also be removed by refactoring with “Extract method”. Also think about extracting complex conditional logic (ones that involve lots of AND/OR logic) to a new method.
- Avoid boolean parameters in functions that create decision branches in your function. Usually this is a sign two functions are hiding inside a single function. Instead remove the boolean parameter and extract logic to a new separate function.
- Remove “dead code”, i.e. code that is never executed. Hopefully you are doing this anyway, but if you have dead code in your function you may be adding needless complexity.
Cyclomatic Complexity metric in Visual Studio
To get the cyclomatic complexity value for your code projects in Visual Studio 2022 navigate to menu:
Analyze -> Calculate Code Metrics
or…
Right mouse button on the project in question -> Analyze and clean up code -> Calculate code metrics
Run Code Metrics for your Solution or an individual code project
A “Code Metric Results” window will appear detailing your methods and their Cyclomatic Complexity (as well as some other metrics).
Cyclomatic Complexity & Code Analysis
Code analysis has a rule for cyclomatic complexity. In your .ruleset file look for rule: CA1502 “Avoid excessive complexity”. Enabling this rule will take action when the cyclomatic complexity reaches 25 or more.
For further information Microsoft has an article on “Code metrics — Cyclomatic complexity”.