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.
Worst things happen always when 2 or more systems are combined because each system might be simple on its own, yet a combination is always much more complex.
It’s not obvious to me because cyclomatic complexity is not a straightforward proxy for the number of systems that are being combined.
It’s also the case that some of the most common sources of vulnerabilities, such as SQL injection, introduce no additional cyclomatic complexity. Heck, buffer overflows are good for your cyclomatic complexity - those array bounds checks are all extra branches.
Buffer overflow checks are really only going to be a linear growth in CC. It's when things move towards exponential growth or higher that it gets really easy to introduce flaws of many kinds.
Now, it's probably not a direct correlation. I'd think security bugs are more likely from programmers that unintentionally raise CC without really realizing it. Aka, overreaching their own knowledge when simpler structures are avaliable.
Sure. It’s just that there’s also so much research that has found that cyclomatic complexity is theoretically ill-founded, and that it tends to underperform other ways of measuring complexity. Most notably, just counting lines of code. (Not per function, in total.)
Here’s an oldie but goodie:
<a href="https://cs.du.edu/~snarayan/sada/teaching/COMP3705/lecture/p1/cycl-1.pdf" rel="nofollow">https://cs.du.edu/~snarayan/sada/teaching/COMP3705/lecture/p...
I’ve personally had better success thinking of it as more of a measure of readability than of quality.
> Weird question to ask, that is pretty obvious.
For something the the prior statement it is never a weird question to ask of there actually evidence of this or just it seems like it should be true so we believe it.
There are tons of things that seem like they would obviously be true, but it turns out they aren't.
System is more complex based on possible states it can have or inputs/outputs.
That is just maths here working. Two systems combined always will have more states and inputs/outputs.
There is nothing to check here as it can be proven purely by maths.
Complex systems having more attack surface are obviously less secure.
They might be less interesting for attackers if they have to scan huge attack surface like IPv6 vs IPv4 but no one is claiming IPv6 network is more secure.
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.
I'd argue that assuming something is obvious without any empirical validation is the root of a huge number of misconceptions that humanity has historically had. There's a reason science suddenly started moving a lot faster after we moved past Aristotle and started measuring things in experiments.
Nice question! Plenty (open) research papers and thesis available the last 40 years -)
Some nice papers: <a href="https://arxiv.org/pdf/2002.07135" rel="nofollow">https://arxiv.org/pdf/2002.07135 , <a href="https://arxiv.org/abs/2411.17343" rel="nofollow">https://arxiv.org/abs/2411.17343, <a href="https://doi.org/10.25300/MISQ/2025/49.1.075" rel="nofollow">https://doi.org/10.25300/MISQ/2025/49.1.075 or see <a href="https://arxiv.org/abs/2411.17343" rel="nofollow">https://arxiv.org/abs/2411.17343
There are many studies about this subject, but mind that complexity in code something different than 'complex' systems. You will need to dive into complexity science , but hard and 'soft' aspects should be taken into account when it comes to cyber security!
Well the first is a discussion without an analysis of existing code, the second is about smart contracts. I'm not convinced that _cyclomatic_ complexity of a function plays a role in security at all. Why:
(a) We have plenty of evidence that buffer overflows etc play a role (caused by using manual memory management), but not so for cyclomatic complexity.
(b) Trying to reduce cyclomatic complexity in one function typically increases the complexity somewhere else, and so is not helping. Often this is just moving stuff around, and sometimes makes things more complex.
runningmike · · focus · HN ↗
[1] <a href="https://nocomplexity.com/documents/codeaudit/complexitycheck.html#complexity-check" rel="nofollow">https://nocomplexity.com/documents/codeaudit/complexitycheck...
thomasmg · · focus · HN ↗
ozim · · focus · HN ↗
Worst things happen always when 2 or more systems are combined because each system might be simple on its own, yet a combination is always much more complex.
bunderbunder · · focus · HN ↗
It’s also the case that some of the most common sources of vulnerabilities, such as SQL injection, introduce no additional cyclomatic complexity. Heck, buffer overflows are good for your cyclomatic complexity - those array bounds checks are all extra branches.
pixl97 · · focus · HN ↗
Now, it's probably not a direct correlation. I'd think security bugs are more likely from programmers that unintentionally raise CC without really realizing it. Aka, overreaching their own knowledge when simpler structures are avaliable.
bunderbunder · · focus · HN ↗
Here’s an oldie but goodie: <a href="https://cs.du.edu/~snarayan/sada/teaching/COMP3705/lecture/p1/cycl-1.pdf" rel="nofollow">https://cs.du.edu/~snarayan/sada/teaching/COMP3705/lecture/p...
I’ve personally had better success thinking of it as more of a measure of readability than of quality.
BoiledCabbage · · focus · HN ↗
For something the the prior statement it is never a weird question to ask of there actually evidence of this or just it seems like it should be true so we believe it.
There are tons of things that seem like they would obviously be true, but it turns out they aren't.
[deleted] · · focus · HN ↗
[deleted]
ozim · · focus · HN ↗
That is just maths here working. Two systems combined always will have more states and inputs/outputs.
There is nothing to check here as it can be proven purely by maths.
Complex systems having more attack surface are obviously less secure.
They might be less interesting for attackers if they have to scan huge attack surface like IPv6 vs IPv4 but no one is claiming IPv6 network is more secure.
anon48293 · · focus · HN ↗
Just more I/O isn’t more complicated nor a bigger risk. More entanglement is more complicated.
Rexxar · · focus · HN ↗
bunderbunder · · focus · HN ↗
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.
saghm · · focus · HN ↗
runningmike · · focus · HN ↗
Some nice papers: <a href="https://arxiv.org/pdf/2002.07135" rel="nofollow">https://arxiv.org/pdf/2002.07135 , <a href="https://arxiv.org/abs/2411.17343" rel="nofollow">https://arxiv.org/abs/2411.17343, <a href="https://doi.org/10.25300/MISQ/2025/49.1.075" rel="nofollow">https://doi.org/10.25300/MISQ/2025/49.1.075 or see <a href="https://arxiv.org/abs/2411.17343" rel="nofollow">https://arxiv.org/abs/2411.17343
There are many studies about this subject, but mind that complexity in code something different than 'complex' systems. You will need to dive into complexity science , but hard and 'soft' aspects should be taken into account when it comes to cyber security!
thomasmg · · focus · HN ↗
(a) We have plenty of evidence that buffer overflows etc play a role (caused by using manual memory management), but not so for cyclomatic complexity.
(b) Trying to reduce cyclomatic complexity in one function typically increases the complexity somewhere else, and so is not helping. Often this is just moving stuff around, and sometimes makes things more complex.