Reduce Cyclomatic Complexity

Beyond Legacy Code — Pragmatic Programmers (135 / 160)

👈 Program by Intention | TOC | Separate Use from Creation 👉

Cyclomatic complexity was first described by Thomas J. McCabe in his December 1976 paper “A Complexity Measure.”[48] It represents the number of paths through code.

Code with just one conditional or if statement has a cyclomatic complexity of two — there are two possible paths through the code and therefore two possible behaviors the code can produce. If there are no if statements, no conditional logic in code, then the code has a cyclomatic complexity of one. There’s only one possible behavior the code can produce. But this grows exponentially. Two if statements have a cyclomatic complexity of four, three have a cyclomatic complexity of eight, and so on. Drive cyclomatic complexity down to as low as you can because, generally speaking, the number of unit tests needed for a method is at least equal to its cyclomatic complexity.

You can’t always achieve a cyclomatic complexity of one, because that’s code with no conditional statements. It’s code that doesn’t branch. It doesn’t take anything into consideration. In fact, the very definition of a computer is a programmable system that wouldn’t be possible without conditional statements. But your methods should have as few conditional statements as possible.

Conditional logic is expensive. If we look at the cost to maintain code based on the keywords of the language, we find that the thirty or so keywords of any programming language don’t have equal costs associated with them. The vastly more expensive keywords are the ones that change control flow: if, switch, unary processing, loops, exceptions…all of these conditional statements change the flow of control. They make it more difficult and more taxing for the brain because suddenly there’s a bifurcation — we have two code paths instead of one, and that splits our attention.

For example, if you have an if statement in your code you must think about and test the true condition and the false condition. This means holding those two conditions in your head, and that can be difficult. I was just looking at some code from a client that had a series of six conditions — a cyclomatic complexity of sixty-four. I can’t hold anywhere near that many conditions in my head. Most people can’t, and that’s why the higher the cyclomatic complexity, the higher the probability that it will have bugs.

If you build each entity with a low cyclomatic complexity, you need far fewer tests to cover your code. I prefer to use techniques like polymorphism in my code, which moves the conditional statements into the creation phase of objects rather than the usage phase. Separating these two phases is one of the most important keys for making code less coupled, simpler to work with, and more maintainable.

👈 Program by Intention | TOC | Separate Use from Creation 👉

Related posts:

Our industry is moving toward functional programming, but your object-oriented experience is still valuable. Scala combines the power of OO and functional programming, and Pragmatic Scala shows you how to work effectively with both. Updated to Scala 2.11, with in-depth coverage of new features such as Akka actors, parallel colle

Even though Scala has sensible static typing and quite a few errors will be caught at compile time, unit testing is still important. It can greatly help to get quick feedback that the evolving code…

Being flexible and allowing has never been my strong point, I’ve always erred more on the side of control, regime and routine. But I find my desperate need for control subsides when I find real…