Unit 5
ePortfolio component: Exploring the cyclomatic complexity’s relevance today
The Cyclomatic Complexity is commonly considered in modules on testing the validity of code design today. However, in your opinion, should it be? Does it remain relevant today? Specific to the focus of this module, is it relevant in our quest to develop secure software? Justify all opinions which support your argument and share your responses with your team.
Cyclomatic complexity is a metric that describes the number of execution paths through a program (McCabe, 1976). Despite being nearly 50 years old, it remains relevant and valuable in modern software development. Its strength lies in its agnostic nature: cyclomatic complexity can be applied across different frameworks, programming languages, and paradigms. Since it counts the distinct paths through a program, it also reflects how difficult the code is to test comprehensively.
While the metric doesn’t identify vulnerabilities directly, it does highlight code that’s harder to understand, maintain, and test. Butler and McCabe (2021) suggest that code with a complexity over 10 already poses a risk. The more paths there are, the more effort is needed to ensure each behaves correctly and securely. This increases the chances of overlooking bugs or vulnerable logic during development, testing, or code review, especially in fast-paced environments.
However, Willenbring and Walia (2024) argue that the threshold value must be decided on per-project basis for the metrics to be useful. For example, some algorithms are inherently complex due to the nature of the problems they solve, making it unrealistic or unnecessary to refactor them. Interestingly, their research documented systems with complexity levels as high as 75. Code at this level is not only hard to test, it is equally hard to fix, since verifying the correctness of changes becomes nearly impossible. (Willenbring and Walia, 2024)
In conclusion, instead of setting hard thresholds, complexity metrics should guide refactoring decisions and encourage discussions about software design without pushing teams to optimize code solely to achieve “acceptable” scores.
References
Butler, C.W. and McCabe, T.J. (2021) ‘Cyclomatic Complexity-Based Encapsulation, Data Hiding, and Separation of Concerns’, Journal of Software Engineering and Applications, 14(1), pp. 44–66. Available at: https://doi.org/10.4236/jsea.2021.141004.
McCabe, T.J. (1976) ‘A Complexity Measure’, IEEE Transactions on Software Engineering, SE-2(4), pp. 308–320. Available at: https://doi.org/10.1109/TSE.1976.233837.
Willenbring, J.M. and Walia, G.S. (2024) ‘The utility of complexity metrics during code reviews for CSE software projects’, Future Generation Computer Systems, 160, pp. 65–75. Available at: https://doi.org/10.1016/j.future.2024.05.038.