# On Writing Readable Code
Code is read far more often than it's written. We all know that, but it's easy to forget when you're in the middle of solving a hard problem. The pressure to "just make it work" can lead to clever one-liners and terse variable names. Resist that impulse.
## Name Things for the Reader
Variables and functions should describe intent, not implementation. `isValid` beats `check1`. `getUserById` beats `fetch`. The next person reading this — including you in six months — shouldn't have to decode abbreviations or guess what `x` represents.
## Prefer Explicit Over Clever
I'd rather see five clear lines than one that uses a regex trick I have to look up. Clever code feels satisfying to write but becomes a maintenance burden. When in doubt, err on the side of boring and obvious.
## Comments Should Explain Why, Not What
If your code needs a comment to explain *what* it does, the code might need refactoring. Comments are best when they explain *why* — the business rule, the historical quirk, the constraint that isn't obvious from the code itself.
## Consistency Is a Feature
Pick a style (or use a formatter) and stick with it. Consistent patterns make code predictable. When everything looks different, every file feels like a new puzzle.
On Writing Readable Code
Why readability matters, and some habits that have made my code easier for others — and my future self — to work with.
#code-quality#readability#clean-code#software-engineering