Cyclomatic complexity is a software metric that assigns an integer value to each subroutine. The cyclomatic complexity metric measures the number of independent paths through a subroutine. Statistical studies have shown a strong positive correlation between cyclomatic complexity and defects, that is, subroutines with higher cyclomatic complexity values are likely to have more defects.
Use cyclomatic complexity data to improve software quality the following ways:
Limit complexity of subroutines during development. The NIST Structured Testing methodology recommends splitting a subroutine when the cyclomatic complexity exceeds 10 or in some circumstances 15. There are cases where higher complexity values are appropriate, in which case a deliberate exception to this general rule can be made. Put another way, subroutines with high complexity should be reviewed and, where appropriate, broken into smaller pieces.
Decide how to allocate testing resources. The cyclomatic complexity metric provides an upper bound for the number of test cases required to achieve complete branch coverage. Note this is not the same thing as achieving complete path coverage.
For example: Two consecutive if-then-else statements require two tests to achieve complete branch coverage, but four tests to achieve complete path testing.
Unfortunately it is not always practical to test all apparently possible paths through an application. The NIST Structured Testing methodology uses cyclomatic complexity to determine the number of white-box tests required to obtain sufficient coverage.