marrakeshh - Fotolia
Many software testing tools include a statistic known as the McCabe cyclomatic complexity metric in their reports. The term itself is a bit confusing, as the metric isn't specifically about code complexity, but is instead a calculation of how many different linear paths of execution there are through a given class or method. The metric itself has important implications for developers writing unit tests who want 100% code coverage.
What is McCabe cyclomatic complexity?
Coined in 1976 by Thomas J. McCabe, the cyclomatic complexity metric is always provided as a whole number. The lower the number is, the fewer linear paths of execution the code contains. A lower number means you'll have to write fewer unit tests in order to ensure a given piece of software has tests for every conceivable permutation. As the McCabe cyclomatic complexity metric rises, you'll need to write more unit tests, and it'll be a challenge to ensure complete code coverage. A low McCabe cyclomatic complexity score of 4 or 5 is always preferred.
Traditional cyclomatic complexity calculations
Since the McCabe cyclomatic complexity metric was coined twenty years before the Java programming language was invented, some of the original verbiage that describes how it works doesn't translate particularly well to the modern realm of object oriented programming (OOP). The original guidance for calculating the McCabe cyclomatic complexity metric (M) discusses edges (E), nodes (N) and connected components (P), giving us the following formula:
M = E - N + 2P
Calculate cyclomatic complexity in Java
In modern parlance, especially for the Java developer, we can simplify the McCabe cyclomatic complexity metric calculation with the following rules:
- Assign one point to account for the start of the method
- Add one point for each conditional construct, such as an "if" condition
- Add one point for each iterative structure
- Add one point for each case or default block in a switch statement
- Add one point for any additional boolean condition, such as the use of && or ||
With exceptions, you can add each throws, throw, catch or finally block as a single point when calculating the McCabe cyclomatic complexity metric. However, given Java's fairly verbose exception handling semantics, counting exception related flows can unfairly malign a well coded method, so it's sometimes wise to ignore the additional points exception handling adds to the McCabe cyclomatic complexity metric total.
Cyclomatic complexity testing tools
Fortunately, it's not necessary for the developer to independently calculate the McCabe cyclomatic complexity metric for every method written. There are plenty of source code quality and code coverage tools that include this metric in their reporting. Three popular examples of cyclomatic complexity testing tools include SonarQube, JaCoCo and the Eclipse Metrics plugin.
But calculating the cyclomatic complexity metric isn't so onerous that you couldn't easily do it on the fly during a code review. When a method looks too long, or it's becoming to hard to test, a good practice is to take a minute and calculate the McCabe cyclomatic complexity of the Java method in question and see if the result supports the supposition that the code is getting a little too complex.
Use these metrics to gauge code quality