Clean code is not a religion

Clean code has a near-religious following in parts of the developer community. Functions must be fewer than 20 lines. Classes must have a single responsibility. Abstraction levels must never mix.

These are useful guidelines. They're also not laws, and treating them as laws produces its own kind of mess.

What Clean Code Actually Means

Clean code is code that's easy to read, understand, and change. That's it. The rules—short functions, descriptive names, single responsibility—are in service of that goal, not the goal itself.

When a rule makes code harder to understand or change, following the rule is wrong.

The Over-Abstraction Problem

I've seen codebases so committed to SRP (Single Responsibility Principle) that a simple operation required tracing through seven layers of abstraction to understand. The principle was followed. The code was unreadable.

// Three classes to multiply two numbers by a config value
$result = (new NumberMultiplier(
    new ConfigReader(new ConfigRepository(new FileReader()))
))->multiply($a, $b);

// Just read the config
$multiplier = config('app.multiplier');
$result = $a * $b * $multiplier;

The second version violates several clean code principles. It's also immediately clear what it does.

When the Rules Help

Descriptive names: always useful. Nobody has ever complained that a variable name was too clear.

Short functions: usually right. When a function is 200 lines, it's usually doing too many things. When it's 50 lines of a single coherent algorithm, shorter would just mean more functions with worse names.

Avoiding duplication: right most of the time. But premature deduplication—extracting a shared abstraction before you understand the pattern—often makes things worse.

The Real Standard

Could a competent developer who has never seen this code understand what it does in 5 minutes? That's the standard. Not 'does it conform to the style guide.'