Clean code is the discipline of writing programs optimized for the reader rather than the writer, because code is read far more often than it is written — by reviewers, future maintainers, and you, months later.¹

A line is written once and read many times — so optimize for the reader.

Core habits

The everyday habits of clean code all flow from one fact: the reader’s time is what you are optimizing.

• Intention-revealing names. A good name says what something is and why it exists without forcing a detour into the implementation. sampleRateHz cannot be misread; sr can. Encode units, avoid cryptic abbreviations and noise words, and pick one word per concept.
• Small, focused functions. A function should do one thing at one level of abstraction. If you can’t name it without “and,” or it doesn’t fit on a screen, it’s probably hiding a smaller function. Extracting steps turns stale comments into self-documenting names.
• Comments explain why, not what. Names and structure already show the what; reserve comments for intent, trade-offs, and non-obvious constraints. A comment that merely narrates the next line will drift and eventually lie.
• Consistent style. Lean on formatters and linters (gofmt, Prettier, Black, rustfmt) so attention goes to logic, not layout, and diffs stay small.

The cost of cleverness

Clever, compact code shifts cost from the writer, who understood it in the moment, to every future reader who must reverse-engineer it. As Brian Kernighan warned, debugging is harder than writing, so code written as cleverly as possible is code you can’t debug.¹ The genuinely hard skill is making complex logic look simple. Clean code is closely tied to DRY, KISS and YAGNI and SOLID, and improving it after the fact is the work of refactoring.

Sources

1. Robert C. Martin — Wikipedia, on the author whose Clean Code popularized this readability discipline. ↩ ↩²

See also

• Refactoring
• DRY
• SOLID
• Abstraction
• Coupling & cohesion
• Unit testing

Learn it step by step

• Writing readable code