The Art of Naming
Write names that reveal intent, avoid confusion, and make code searchable.
Reveal Intent
A name should answer why a variable exists, what it does, and how to use it — without a comment.
Hides intent
elapsed (days? hours? ms?)
s (score? size? seconds?)
Reveals intent
daysSinceCreation
userScore
Avoid Disinformation
Don't name a HashSet of accounts accountList. Don't use l (looks like 1) or O (looks like 0). Names that lie are worse than no names.
Make Distinctions Mean Something
getUser vs getUserInfo vs getUserData — what's the difference? If you can't explain it, collapse them into one. Noise words (Info, Data, Manager) add length, not meaning.
Say It Out Loud
If you can't pronounce it, you can't discuss it. ymdhms → timestamp. Names must also be searchable — avoid single-letter variables except for loop counters.
Code Challenge
Edit the code below and try to rename everything before revealing the clean version.
💡Key takeaway
A good name is a promise. It tells the reader exactly what to expect — no comment needed.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: Try the 'explain to a colleague' test: describe what d, s, and tmp represent in the business domain out loud. The words that come naturally in that explanation are the right variable names.
✗ Your version