Overall cyclomatic complexity is a useful metric, but it does have one shortcoming when used with modern languages: it was invented before polymorphism really became a thing.

That means that it really only counts explicit branching. So, for example, in an OO language like C#, calling a virtual method doesn’t increment cyclomatic complexity even though the method invocation could go down many code paths. Potentially thousands if you’re dealing with a common interface like IEnumerable. If you’re working on a library then the number of potential code paths in this kind of situation is unbounded.

As an aside, it’s interesting to think how it might apply to a language like Smalltalk that doesn’t even have if or switch statements.

OO isn’t the only monkey wrench, either. Higher-order functions also introduce forms of branching that cyclomatic complexity doesn’t measure.

Again that doesn’t make it a useless metric. Just don’t think that a cyclomatic complexity limit in your codebase is some sort of maintainability panacea. Some of the least comprehensible functions I’ve deciphered had quite low cyclomatic complexities.

I don't disagree that functions with many execution paths are harder to read, but I do believe that the solution given here; 'just split it into multiple functions' frequently makes a function even harder to read. It forces you to scroll back and forth between code.

I think generally when you run into something like this, the better way to handle it is to sit back, and reconsider how your overall handling is designed.

Fun story: at my previous aaaawful company CC was discovered as a thing to care about at about the same time as PMs and managers were encouraged to land code changes using the _then_ quite terrible AI tooling (this was a year or two ago). Cue an avalanche of completely unreviewable diffs.

From a security perspective cc is highly relevant. I use it to get a solid rating of the security aspects of Python code. I use [1] which is solid and proven.

[1] https://nocomplexity.com/documents/codeaudit/complexitycheck...

I must have always confused cyclomatic complexity with nesting depth.

I do agree you need to keep nesting depth down, because that really does break my brain.

But a long sequence of cases or elifs needn't always be a problem, and here they make it sound like it is.

I made CC part of my deterministic quality gate[0] for agents. Not sure how much of it is placebo, but overall I've seen the gate catch a lot of cases where the agent strayed from the constraints of the particular project.

[0]: https://github.com/ivmirx/agentic-quality-loop

Anyone using tools like ndepend or others to help guide agents in refactors?

Personally I have a some tools that build dependency graphs (C# and Python) and store the results in a local database. Agents seem quite good at poking at this and coming up with refactor ideas. Graph analysis tools are useful here, simple application will detect cyclical dependencies, but I encourage the agents to use more complex tools like clustering to poke at the data.

[flagged]