When writing code, we must focus on designing code that will be maintainable; on writing small, readable methods to meet defined standards.
Through different literature and data sources, the metrics vary. As we have had the opportunity to see in the example of the C# algorithm for calculating the complexity of the code, approaches differ from one language to language. Unfortunately, it’s still language-dependent.
In his book “Code that Fits in Your Head Heuristics for Software Engineering,” Mark Seemann focuses on the number 7 as a threshold for method complexity. And if the method exceeds the upper limit, it needs to be broken down or extracted as a separate method. However, due to the diversity of software development approaches, different levels of knowledge of development teams, and the complexity of the software solution, the defined standards of code complexity also vary. So, we can find some approaches that advocate the number 10 as the upper limit, even higher, up to 15.
According to Thomas McCabe, the proposed upper value is 10. Limits over ten should be reserved for projects with several operational advantages over typical projects, such as an experienced team, a modern programming language, structured programming, code walkthroughs, and a comprehensive test plan.
Remember, the higher the complexity, the higher number of tests needed. In the table below, we can review the proposed metric for the project. Of course, metrics can vary, but presented values should be valid referent points for defining the complexity thresholds.
Figure 9. Metrics threshold for Cyclomatic Complexity.
As previously stated, cyclomatic complexity counts the number of logical paths through a function. The algorithm counts the decisions in the code, sums them up, and calculates the complexity value.
Unfortunately, there are some pitfalls if we only rely on cyclomatic complexity as the final insurance of the code quality and maintainability.
Figure 10. Complex cyclomatic complexity value.
If we compare the complexity value from Figure 7 with the complexity value from Figure 10, we can easily detect that value from Figure 7 is higher than Figure 10.
Does this mean that code from Figure 7 is more complex than code from Figure 10?
Unfortunately, no. If we compare the code from Figure 7 with the code from Figure 10, the code from Figure 7 can be easily read and understood without effort, while the code from Figure 10 requires some additional effort to understand.
More specifically, cyclomatic complexity doesn’t reveal the relative effort needed to understand or modify a piece of code.
With additional practices in mind, can we conclude that analyzing the cyclomatic complexity is a poor practice to follow when trying to reduce the code complexity?
Analyzing the cyclomatic complexity metric is not necessarily a poor approach to code quality because it closely correlates to cognitive complexity. The higher the cognitive complexity, the harder it is to read and maintain the existing code base.
Generally speaking, too high cyclomatic complexity is a symptom of problems in the existing codebase or a potential cause of future problems. We should keep in mind that the more complex a given block of code is, the harder it is to read and maintain.
