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.