Naming variables well in 2026 comes down to one rule: a name should tell the reader what it holds and why, with no comment needed. Be specific over clever, match the convention of your language (camelCase in JavaScript, snake_case in Python), make booleans read like yes-or-no questions, and avoid cryptic abbreviations or single letters outside tiny loops. Good names are the cheapest readability win in programming, and they prevent real bugs. Here are the rules with concrete before-and-after examples.
Why names matter more than you think
Code is read far more often than it is written. A vague name like data or temp forces every future reader, including you, to dig through the logic to understand what it is. A name that states intent removes that work. Naming is not cosmetic; mislabeled variables hide bugs and slow down everyone who touches the file, which is why it is one of the cheapest ways to write better code.
// unclear: what is in d, and what does this loop do?
for (let i = 0; i < d.length; i++) {
if (d[i].a > 18) r.push(d[i]);
}
// clear: the names explain themselves
for (const user of users) {
if (user.age > 18) adults.push(user);
}
Both snippets do the same thing. Only one explains itself.
The core rules
| Rule |
Bad |
Good |
| Reveal intent |
d, temp, val |
adults, retryCount, totalPrice |
| Be specific |
list, item |
activeUsers, selectedItem |
| Booleans ask a question |
active, flag |
isActive, hasAccess, canEdit |
| Match the convention |
user_Name (in JS) |
userName (JS), user_name (Python) |
| Pronounceable, searchable |
usrCnt, ymdhms |
userCount, timestamp |
| Singular vs plural fits |
user (an array) |
users (an array), user (one item) |
The throughline: optimize for the reader, not for fewer keystrokes. Editors autocomplete, so a longer clear name costs you nothing.
Conventions by language
Each language community has a house style. Follow it; consistency inside a file matters more than your personal preference.
- JavaScript and TypeScript: camelCase for variables and functions, PascalCase for classes and components, UPPER_SNAKE for constants.
- Python: snake_case for variables and functions, PascalCase for classes, UPPER_SNAKE for constants.
- Go: camelCase or PascalCase, where an uppercase first letter means the name is exported.
- Rust: snake_case for variables and functions, PascalCase for types.
When you join an existing codebase, mirror what is already there even if you would have chosen differently. Mixed styles are worse than any single style.
What to skip
- Skip single letters outside short loop counters or well-known math like x and y.
i in a three-line loop is fine; u for a user is not.
- Skip abbreviations that only you understand.
acctBal saves four characters and costs every reader a guess.
- Skip type names in variables.
userArray and nameString add noise; users and name are enough.
- Skip negated booleans.
isNotReady makes conditions confusing; prefer isReady and negate at the check.
- Skip generic catch-alls like
data, info, obj, and temp when a specific noun exists.
FAQ
Should variable names be long or short?
As long as they need to be to read clearly, and no longer. A loop counter can be one letter; a value used across a function deserves a full, descriptive name. Clarity beats brevity.
Is camelCase or snake_case better?
Neither is objectively better; it depends on the language. Use camelCase in JavaScript and Java, snake_case in Python and Rust, and always match the existing codebase.
How should I name boolean variables?
Phrase them as a yes-or-no question with a prefix like is, has, can, or should: isActive, hasPermission, canSubmit. Conditions then read like plain English.
Do good names really reduce bugs?
Yes, indirectly but meaningfully. Clear names make logic easier to follow, so mistakes are spotted in review and reading rather than hiding behind vague labels like flag or x.
Where to go next
Write cleaner code overall, learn to write a function well, and pick up clear commenting habits.