What is Clean Code?

Clean Code is the set of practices aimed at making source code readable, understandable and easy to change. The concept was popularized by the book of the same name by Robert C. Martin, published in 2008.

The premise underneath it all is economic: code is read far more often than it is written. Optimizing for writing saves minutes once; optimizing for reading saves hours repeatedly, for years, for everyone who passes through — including you six months from now.

Names that need no explanation

The most profitable principle and the most neglected one. A good name removes the need for the comment that would explain the bad one.

// hard to read: what are d, l and 0.1?
function calc(d, l) {
  return d.filter((x) => x.t > l).map((x) => x.v * 0.1);
}

// the code explains itself
const TAXA_COMISSAO = 0.1;

function calcularComissoes(vendas, valorMinimo) {
  return vendas
    .filter((venda) => venda.total > valorMinimo)
    .map((venda) => venda.valor * TAXA_COMISSAO);
}

Core principles

• Single responsibility — each function does one thing. If the name needs an "and" to describe it, it probably does two.
• Small functions — what fits on the screen without scrolling is easier to understand as a whole.
• Avoid deep nesting — early returns eliminate pyramids of conditionals.
• DRY in moderation — remove real duplication of knowledge, not code coincidences that will evolve in different directions.
• Comments explain the why — the code already says the what; the comment should record the decision that is not obvious.
• Explicit error handling — silent failures turn simple bugs into long investigations.

The criticisms — which also have a point

The counterarguments are worth knowing, because dogmatic application causes real problems. Fragmenting code into tiny functions can reduce readability, forcing you to jump through ten files to understand a single flow. Abstracting too early, before knowing how the requirement will evolve, produces wrong abstractions that cost more than the duplication they would avoid. And "clean" has a subjective component that the book presents as universal.

The more balanced reading treats the principles as heuristics, not rules. The real goal is not reaching a particular aesthetic, but reducing the cost of changing the software tomorrow. When a principle increases that cost, it should give way.

How to apply it in practice

Tools automate the mechanical part: linters catch structural problems and formatters like Prettier end style debates. That frees code review for what matters — clarity of intent, good names and design decisions. The boy scout rule sums up the incremental approach well: leave the code a little better than you found it.