Nice idea. Our new CTO brought in a tool he made for analyzing cyclomatic complexity and it’s been useful since we’re a heavily AI-forward shop.
BTW, you can avoid your comments being flagged and killed by writing them yourself! I know it’s tempting to offshore it to AI (especially after you’ve vibe-coded a whole project) but some genuine human communication goes a long way.
I know cyclomatic complexity has been heavily debated for a long time, but I do think it’s valuable. It’s really good at highlighting common annoyances like overly clever code, nested ternaries, dense functions with too many branches…
The only thing is that these issues seem like human code problems and IME LLMs don’t really write code like this anymore. It’s almost the opposite in python, actually, where Claude leans on writing lots of 2-3 liner private utils which is a separate kind of complexity and organization problem.
I still find it useful specifically for React where it’s frustratingly normalized to write many branches in your JSX though.
The difference to previous CC use, is the the change impact formula looks at the complexity already in the class/file. Typical CC just looks at the function it is change and not the context of the change. The Change Impact formula incorporates that to avoid god class and god method issues. Plus multiplying by number of files punishes for non-cohesive code bases. For me it puts the intuition of high cohesion and low coupling into a measurable metric.
Yes, I've run it against a bunch of open source projects with long histories (before AI) to see if it predicts bugs. Seems file size is still a better predictor. However, for the projects where good coding was strictly adhered to and others that were not, it showed the differences appropriately. So I've found it useful in general for Software erosion.
Maybe I missed it, but it look like this has just a single metric. Maybe instead of making a new project, you could try to get this metric added to a existing tool like https://dekobon.github.io/big-code-analysis/index.html which already has dozens of metrics.
Claude is pretty good at adding focused changes and if a fix is already present, then it correctly points it out rather than adding unnecessary refactors.
Kind of ironic that this thing purports to “gate” slop, yet the entire project is slop, including the README and even the authors comments here. I hate this timeline.
What score do we get for a group of fixes to single line bugs that are obvious once spotted?
There is an implication that all AI changes add complexity and reduce quality, but it is obvious that the quality and complexity is a property of the code not the writer, so all equivalent changes should be equal no matter what the shource.
How do clear improvements to make something simpler yet more functional score under this system?
The problem with cohesion is understanding what is "single purpose". Nothing can determine this without interpreting the code and making a judgement call on whether it needs to be refactored into two or more classes.
So I'm looking to approximate this. Instead of looking for cohesion, Change Impact formula approximates this by looking at existing complexity in the file.
If the change adds more complex functions to an already complex class, it scores high. Smell of it doing too many things.
If the change adds a complex function to an empty file, it's likely just a complex single problem.
If the change adds simple change to complex file, then if this happens too many times, we flag it for concern. Especially if it changes a lot of other files too.
So it's not mean to measure your code exactly. It's meant to highlight smell that needs investigation. And the formula points out the classes that need looking at.
Plus I'm not sure that all changes are equivalent. I'm not looking at single one off changes. I'm looking at 60 changes in a row. The first 20 might go through fine. However, after the changes pile on, there needs to be some refactoring to keep the code clean. This is trying to catch it before it becomes a mess.
> If the change adds a complex function to an empty file, it's likely just a complex single problem.
How do you determine that this is correct = adding complexity to a single file vs adding less complexity to multiple files that this one file then orchestrates.
Most static code analysis looks for bugs or just too complex functions.
The novelty of Change Impact is it looks at the context of the complexity. Adding complexity to something already complex should be flagged for review.
I've not come across any static code analysis so far that has provided this.
And in my own research of architectures, I came to this formula.
26 comments
[ 35.7 ms ] story [ 46.4 ms ] threadBTW, you can avoid your comments being flagged and killed by writing them yourself! I know it’s tempting to offshore it to AI (especially after you’ve vibe-coded a whole project) but some genuine human communication goes a long way.
The only thing is that these issues seem like human code problems and IME LLMs don’t really write code like this anymore. It’s almost the opposite in python, actually, where Claude leans on writing lots of 2-3 liner private utils which is a separate kind of complexity and organization problem.
I still find it useful specifically for React where it’s frustratingly normalized to write many branches in your JSX though.
Claude is pretty good at adding focused changes and if a fix is already present, then it correctly points it out rather than adding unnecessary refactors.
There is an implication that all AI changes add complexity and reduce quality, but it is obvious that the quality and complexity is a property of the code not the writer, so all equivalent changes should be equal no matter what the shource.
How do clear improvements to make something simpler yet more functional score under this system?
The problem with cohesion is understanding what is "single purpose". Nothing can determine this without interpreting the code and making a judgement call on whether it needs to be refactored into two or more classes.
So I'm looking to approximate this. Instead of looking for cohesion, Change Impact formula approximates this by looking at existing complexity in the file.
If the change adds more complex functions to an already complex class, it scores high. Smell of it doing too many things.
If the change adds a complex function to an empty file, it's likely just a complex single problem.
If the change adds simple change to complex file, then if this happens too many times, we flag it for concern. Especially if it changes a lot of other files too.
So it's not mean to measure your code exactly. It's meant to highlight smell that needs investigation. And the formula points out the classes that need looking at.
Plus I'm not sure that all changes are equivalent. I'm not looking at single one off changes. I'm looking at 60 changes in a row. The first 20 might go through fine. However, after the changes pile on, there needs to be some refactoring to keep the code clean. This is trying to catch it before it becomes a mess.
How do you determine that this is correct = adding complexity to a single file vs adding less complexity to multiple files that this one file then orchestrates.
The novelty of Change Impact is it looks at the context of the complexity. Adding complexity to something already complex should be flagged for review.
I've not come across any static code analysis so far that has provided this.
And in my own research of architectures, I came to this formula.