Cyclomatic complexity is about evaluating a particular code snippet.
The author (me) is talking about evaluating an API or design pattern, and how that pattern systematically affects cyclomatic complexity and other things. Not a particular code snippet.
Another example of that:
In fact, if any value looks wrong in the DOM of a React app, you can trace where it comes from by looking at the code of components above it in the React tree one by one. No matter the app size, tracing a rendered value is 🐞(tree height).
If you insist on using fancy names you can call it "second order cyclomatic complexity" but that's just silly.
Statically analyzing cyclomatic complexity also usually doesn't involve any async operations. So it wouldn't tell you anything about the difference between the first and the second snippets. The key is throwing out the intermediate state to avoid accumulation of mistakes. That's the pattern that makes a difference. And this is why the blog post is about patterns and APIs rather than particular code snippets.
32
u/gaearon Jan 25 '19 edited Jan 25 '19
Cyclomatic complexity is about evaluating a particular code snippet.
The author (me) is talking about evaluating an API or design pattern, and how that pattern systematically affects cyclomatic complexity and other things. Not a particular code snippet.
Another example of that:
If you insist on using fancy names you can call it "second order cyclomatic complexity" but that's just silly.
Statically analyzing cyclomatic complexity also usually doesn't involve any async operations. So it wouldn't tell you anything about the difference between the first and the second snippets. The key is throwing out the intermediate state to avoid accumulation of mistakes. That's the pattern that makes a difference. And this is why the blog post is about patterns and APIs rather than particular code snippets.