Comment by bunderbunder

Cyclomatic complexity is funny math, though. The article demonstrates how. They took a single function that makes state changes to an object, and scattered that logic across four different functions that make the same set of state changes. That’s all. This had adverse impact on the complexity of the system - the logic and behavior of the top level function are the same. It’s just as stateful and has just as many linearly independent code paths. They just got shuffled around to game the way that cyclomatic complexity treats function calls.

But in the process they created three additional functions to call. That means the overall system has more possible code paths, and introduces a need to think about what happens if they are ever called from somewhere other than the original entry point. Introducing ways to screw things up that did not previously exist is not reducing complexity and it is not increasing maintainability.

Your insistence that this somehow managed complexity is exactly why I wrote the top level comment cautioning people about how they interpret cyclomatic complexity. If you don’t understand what it’s actually measuring - not complexity, not really - then it will mislead you into bad decisions.