Clean Code in Real Projects: What to Apply, What to Adapt and What to Ignore

There's a moment every team recognises: someone opens a two-year-old file, stares at a 400-line function called processData and says "this needs a rewrite". Someone else answers: "don't touch it, it works". Both are right, and Clean Code lives in that tension.

Since Robert C. Martin published the book in 2008, "clean code" has become both a de facto standard and a religion. And like every religion, it has devotees who apply every rule to the letter and heretics who ignore all of them. This guide is about the profitable middle ground: which rules always pay off, which depend on context, and which you can ignore without shame at your next retro.

What Clean Code Really Is (and What It Isn't)

Clean Code isn't a style or an aesthetic: it's an economic decision. Code is read dozens of times more than it's written — by you in six months, by the colleague who inherits your module, by whoever debugs an incident at three in the morning. Writing clean code means paying a small surcharge today to make all those future readings cheaper.

And it isn't:

• A list of sacred rules. Martin himself presents his as heuristics learned from experience, not commandments. Treating them as dogma produces "clean" code that nobody can maintain.
• A synonym for perfect. Clean code is code that communicates its intent and accepts the next change without pain. Nothing more. Chasing perfection is procrastinating with a clear conscience.
• A substitute for design. You can have impeccable five-line functions on top of a rotten architecture. Cleanliness operates at the small scale; structure comes from decisions like the ports and adapters of hexagonal architecture.

The Rules That Always Pay Off

There's a core of practices whose return doesn't depend on context: they cost little and always pay. If you only keep one section of this article, make it this one:

• Names that tell the truth. calculateLoyaltyDiscountPrice instead of calc. The name is the documentation that never goes stale. If you can't find a good name, the function probably does two things.
• Small functions with a single responsibility. Not for aesthetics: because a function that does one thing can be tested, named and reused. One that does five can only be feared.
• Dead code gets deleted. Commented-out code, "just in case" methods and branches that never run aren't prudence: they're noise somebody will have to read. That's what git is for.
• Tests are part of the code. A change without tests is a loan the next person repays. The testing pyramid tells you how many and which kind; what's non-negotiable is that they exist.
• Leave the code better than you found it. The boy scout rule: every time you touch a file, improve something small. It's the cheapest strategy against technical debt because it spreads the payment across daily work instead of hoarding it for a rescue project that never comes.

The Ones You Must Adapt to Context

The second category is where engineering judgement is won or lost: valuable rules that turn against you when applied with a sledgehammer.

• DRY (Don't Repeat Yourself). Removing duplication is healthy; removing it too early couples things that only coincided by accident. The practical heuristic: tolerate the first copy, eye the second suspiciously, refactor the third. Duplicating is cheap; decoupling a premature abstraction is very expensive.
• SOLID. Five principles designed for code that changes a lot. Applied where change actually happens, they're gold; applied preventively across the whole codebase, they produce interfaces with a single implementation and factories of factories. SOLID isn't a destination: it's a response to pain.
• Comments. "Good code documents itself" is half true. The what documents itself if the names are good; the why — why this approach was chosen, what was tried before and failed — doesn't fit in a name. Comment the why, never the what.
• Test coverage. 100% coverage guarantees nothing (you can execute every line without asserting anything about the result) and chasing it turns tests into a burden. Cover the business rules and the paths that break things; we'll forgive you the DTO getter.

What You Can Ignore Without Guilt

And then there's the paraphernalia: practices that sound professional but subtract more than they add in most projects.

• Speculative abstractions. "One day we'll have another payment provider, let's make an interface". Maybe. But until the second real case arrives, the interface is a tax on reading with zero return. YAGNI isn't laziness: it's respect for the future reader.
• Patterns by catalogue. If your code needs a class diagram to be explained, it isn't sophisticated: it's baroque. A pattern is an answer to a specific problem; without the problem, it's decoration.
• The formatting wars. Tabs versus spaces, braces here or there: it has the least impact on maintainability and burns the most energy. Set up an automatic formatter, commit it to CI and never speak of it again.
• Purposeless refactors. Rewriting a module "because it's ugly" when it hurts no metric is vanity, not engineering. Cleanliness is justified by cheaper future changes; if nobody will ever touch that code, its ugliness is free.

The Economic Argument

The book's classic chart is still the best justification: without discipline, the cost of every change grows with the age of the code until the team spends more time dodging the system than improving it. With clean code, the cost stays flat. The crossover arrives sooner than it seems: in a project with a lifespan of years, the discipline pays for itself in months.

The practical conclusion for talking to the business: Clean Code isn't a developer preference, it's the difference between "we can change that next week" and "that's impossible without rewriting half the system". When someone questions the time invested in cleanliness, the right question isn't how much cleaning costs, but how much being unable to change costs.

Common Mistakes When Adopting It

1. Adopting it overnight. Deciding on Monday that "from today everything will be clean" produces friction, impossible-to-review PRs and abandonment within three weeks. It's adopted through small habits: names first, small functions next, the rest over time.
2. Turning it into a code review weapon. If reviews become heresy hunts, the team learns to fear feedback, not to write better. The boy scout rule applies to people too: teach by example, not by shaming.
3. Cleaning what doesn't hurt. Spending two days on a script that runs once a year is a luxury the project won't thank you for. Cleanliness follows change: clean what you touch, not what annoys you from a distance.
4. Confusing clean with short. A two-line function hiding side effects is worse than a twenty-line one that reads top to bottom. The metric isn't length: it's how long a stranger takes to understand what it does.
5. Cleaning without tests underneath. Refactoring uncovered code is trapeze without a net. If the module is ugly and has no tests, the first act of cleaning is writing the tests that characterise its current behaviour — then you touch it.

In Short

Clean Code is an economic decision: code is read far more than it's written, and cleanliness makes every future reading cheaper. Honest names, small functions, tests and the boy scout rule always pay off. DRY, SOLID, comments and coverage must be adapted to context. And you can ignore speculative abstraction, catalogue patterns and formatting wars without drama. The goal isn't pretty code: it's a system that's still changeable two years from now.

If your team argues more about style than about the business, or if every change costs more than it should, a code audit puts numbers and a plan on the table. Tell us about your case →

Keep reading: Technical debt: what it really is, when it's good and how to pay it down.