Complexity isn't felt, it's measured

Every team has a file nobody wants to touch. When you ask why, the answer is always the same: «it’s just really tangled». It’s an honest intuition, and almost always right — but it isn’t data. You can’t prioritize it, track it over time, or argue about it without it turning into a matter of taste.

Code complexity doesn’t have to stay a feeling. It can be measured, function by function, and that changes the conversation.

Three numbers, three different questions

There is no single complexity metric, but several that answer different questions. Cyclomatic complexity counts the independent paths through a function: how many cases you’d have to test to cover it. Cognitive complexity aims at something closer to the experience of reading it — it penalizes the nesting and control-flow jumps that force your mind to carry context. And source lines of code (SLOC), without blanks or comments, give the raw scale.

The three together say more than any one alone. A function can be long but flat, or short and devilish.

Measuring doesn’t replace judgment. It points to where to apply it.

Measuring isn’t punishing

The most common mistake is using these numbers as a stick to assign blame. That’s not what they’re for. A complexity metric is a smoke detector: it tells you where to look, not what to do. Sometimes a complicated function is justified by the domain it models. Other times it’s pure debt waiting to blow up. The number doesn’t tell them apart — that part is human work.

What it does do is take complexity out of the realm of opinion. When «this module feels tangled» becomes «this function has a cognitive complexity of 34», it stops being a complaint and starts being a task.