Yes, the formula does make some approximations.

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.

▲

eithed 2 hours ago | parent [-]

> 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.

▲

sagenschneider 2 hours ago | parent [-]

Yes, you are right that looking at one commit doesn't tell you much.

It's looking at the nature of on going changes.

A single complex file written once and never touched is likely a good cohesive file about a single problem solved.

However, if we start making many changes to that file increasing it's complexity, it's likely not the problem getting more complex. It's likely we're adding more purposes to the file, eroding it's cohesion. This is the signal I'm trying to catch to avoid a mess starting.

▲

eithed 2 hours ago | parent [-]

Right, so really any fresh file is more or less fine (would still evaluate cyclomatic complexity). It's the quantity/frequency of changes that matters (or CRAP)

	▲	sagenschneider an hour ago \| parent [-]
		Yes The research I'm actually doing is comparing: - mutative architecture (Spring) which as single method handling the request. It grows in complexity as changes are added - additive architecture (OfficeFloor) which does function injection. A pipeline of functions, where new functionality is an injected function as a step in the pipeline (i.e. adding functions, rather than mutating a single handler function) What I've found is the complexity of the overall system is what it is. Between both architectures, the overall CC is the same. However, the distribution is very different. Mutative architectures pile changes into god handler method. Additive architectures spread the complexity into smaller manageable files. This, however, does not come with perfect wins. Spread also means AI doesn't read the dispersed files. AI is good with complexity and tends to fix things when it sees them (so does fix bugs in god classes). But this is only to a certain point when the complexity then comes to overwhelm the AI. The formula is trying to catch the mess of on going changes at a point before the expensive refactoring or rewriting becomes necessary.