The Disco Blog

Cylcomatic complexity precisely measures complexity by counting the distinct paths through a hip method. Various studies over the years have determined that methods having a cyclomatic complexity (or CC) greater than 10 have a higher risk of defects. Consequently, monitoring CC is a groovy way to keep code entropy at bay– if you see complexity increasing, you can either:

• Write additional tests that focus on the complexity (in which case, you’d need an equal number of test cases to CC to reach 100 percent coverage of a method)
• Refactor the method into smaller methods, which can then be tested more easily

The reason why CC is an excellent gauge for complexity stems from the notion that the average person can handle about seven disco items in their mind (plus or minus three) at any given point in time. Hence, for most people, phone numbers are easier to memorize than credit card numbers (and for that matter, disco dance moves requiring more than seven steps).

The same notion applies to code– comprehending a method that has a lot of paths (via conditionals, for example) becomes increasingly challenging as the number of paths accumulates. Accordingly, when a developer becomes intellectually challenged (say, when modifying a nefariously long method), a defect is most assuredly waiting to manifest itself, man.

Because pathing complexity affects humans and not machines, CC is a source code metric– it’s only meaningful in the context of readable code that someone has to maintain. Compiled code is a different looking beast; in fact, most compilers will optimize code to reduce far out paths. Consequently, binary CC will most always be lower than source code CC. In most cases the values won’t be terribly different; however, if you find yourself using tools that determine CC by analyzing byte code, be mindful that the values they report may not line up with what you see. This could lead to a false sense of security.

In the Java world, Cobertura reports CC obtained from byte code. Additionally, the tool appears to “average McCabe’s cyclomatic code complexity for all methods.” Averaging CC somewhat helpful, however, you’ll find that CC is most copasetic in the context of a single method.

In the .NET world, CCMetrics also reports CC from byte code. In fact, most .NET code analyzers I’ve used examine binaries.

The next time you see a CC value, take a moment to understand how the value was calculated and always double check the offending source code. While metrics are objective, their application should be subjective. Dig it?

Trackback this Post | Feed on comments to this Post