What does clean code mean in everyday projects?
The term is readily sold as a quality promise and just as readily used to justify rebuilds that nobody ordered. This article says what actually lies behind it — and what it does for you.
What you will learn
Why readability is money
Code is written once and read many times afterwards: with every change, every bug hunt, every change of developer. What saves a quarter of an hour when writing can cost an hour on the tenth reading.
So the question is not “is the code beautiful” but: how long does someone who did not write it need to make a change safely? You pay for that time with every extension.
Five properties you can check
// Hard to read: everything nested, nothing named
if ($a !== null) {
if ($a->getStatus() === 2) {
if (count($a->getItems()) > 0) {
// ... the actual work, four levels deep
}
}
}
// Readable: special cases first, business terms in the names
if ($auftrag === null) {
return;
}
if (!$auftrag->istFreigegeben()) {
return;
}
if ($auftrag->positionen() === []) {
return;
}
// ... the actual work, without indentationA real-world example
When the business terminology is missing
In an application we took over, a central method was called `process()`. It checked stock, created a record, sent two emails and wrote a log entry. Every change to one of those four parts meant understanding the whole method — and hoping not to break the other three.
Splitting it into four named steps did not change a single letter of business logic. It turned the next change from a risk into a routine. That is the whole point.
Where the term is overused
“That is not clean code” is not an argument as long as nobody says which concrete change becomes more expensive as a result. A rebuild that only changes the form has a price and no measurable benefit — and it carries the risk of altering behaviour that works.
So we handle it this way: we restructure what is being touched anyway, and only to the extent the upcoming change requires. A rebuild as a project in its own right needs a justification with a name — for instance a place where errors have repeatedly arisen.
Common misconceptions
About the author
Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that come up in real projects.