3 reasons to monitor cyclomatic complexity

Cyclomatic complexity metrics are a simple metric that developers and teams can use to not only minimize the complexity of their functions, but also to ensure they’re testing all paths through their code.

I often feel that McCabe’s Cyclomatic Complexity is a fundamental metric that every manager and software developer in the world must surely follow. Again and again I am amazed at how few know and use cyclomatic complexity. Cyclomatic complexity is a measure that can be performed on software functions to measure the number of linearly independent paths in that function. In other words, it tells us how many branches there are in each function. Why might a developer want to track cyclomatic complexity? In today’s article, we’ll explore the top three reasons to monitor cyclomatic complexity.

Reason #1 – This tells us the risk of a feature containing undiscovered bugs.

In software development, we constantly manage risk. The risk that we will deliver on time or not. The risk that we run out of money before the product is shipped. The risk that a function we have written and tested has bugs that we have not yet discovered! Cyclomatic complexity tells us the subjective risk that a given feature has of containing a bug. For example, the table below provides widely accepted cyclomatic complexity ranges and the risk associated with them.

Developers want to ensure that their functions stay very close to the 1-10 range to minimize the risk of undiscovered bugs. In fact, any function with more than fifty linearly independent paths is untestable, which obviously carries a very high risk of bugs.

Reason #2 – This tells us the risk that modifying a function will inject a bug

Have you ever tried to make changes to a function that spanned several hundred lines of code? It is often stressful, tiring and time-consuming. Why? Because it usually doesn’t work very well. A minor change and things break. Fix it, and something else breaks. Large and complex functions often contain too many paths for our human short-term memories to follow at once! The result is bugs in the code.

Cyclomatic Complexity provides us with a numeric value that tells the user the risk of a function having a bug, but also the risk of a new bug being injected into the code if we try to modify the function. Tracking cyclomatic complexity can help us determine if we are preparing to enter a quagmire or if the changes we are about to make will go smoothly. Take a moment to review the bug injection risk chart below. [1][2]. For a simple function of complexity less than 11, the risk is only 5%! However, a function complexity between 11 and 20, and suddenly there is a 20% risk! The risk only gets worse with increasing complexity.

Reason #3 – This tells us the minimum number of test cases required to test our functions

The first two reasons to track cyclomatic complexity really drive us to properly manage software risk and minimize the complexity of our software. My favorite reason for tracking cyclomatic complexity is that it tells us the minimum number of test cases required to test our functions successfully. For example, if you just wrote a function that has a cyclomatic complexity of twelve, you need at least twelve test cases to test each path through the function. In fact, chances are you’ll need more than twelve for testing boundary conditions with varying values, etc. If you only have three test cases for this function, the probability that there are bugs in the function is relatively high.

As much as I like to use test-driven development when writing my embedded software, I will always use cyclomatic complexity values ​​to help me check that I haven’t overlooked anything. Cyclomatic complexity in these cases can help act as a consistency check to ensure developers are testing all paths through their code. Remember though that just because you’re testing every path or getting 100% test coverage doesn’t mean there are still no bugs in the code. The tests may not have been designed to catch them.

conclusion

Cyclomatic complexity metrics are a simple metric that developers and teams can use to not only minimize the complexity of their functions, but also to ensure they’re testing all paths through their code. You’ll find that cyclomatic complexity metrics can be found in simple free tools like pmccabe or Metrix++, as well as commercial metrics trackers. I would recommend developers to use them during development and as part of the reporting process in your CI/CD pipelines. You will find that the ultimate reason for monitoring cyclomatic complexity is that it will save your company time and money and provide a higher quality code base.

References

[1] McCabe, Thomas Jr. Software Quality Metrics to Identify Risk. Presentation to Department of Homeland Security Software Assurance Task Force, 2008.

[2] (http://www.mccabe.com/ppt/SoftwareQualityMetricsToIdentifyRisk.ppt#36) and Laird, Linda and Brennan, M. Carol. Measurement and Estimation Software: A Practical Approach. Los Alamitos, CA: IEEE Computer Society, 2006.


Jacob Beningo is an embedded software consultant specializing in real-time systems based on microcontrollers. He actively promotes software best practices through numerous articles, blogs, and webinars on topics such as software architecture design, integrated DevOps, and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees, including a Masters in Engineering from the University of Michigan.

Related content:

To learn more about Embedded, subscribe to Embedded’s weekly email newsletter.



Sharon D. Cole