What makes a good variable name, and why does it matter so much?
A good name states what the thing is, in the language of the problem, so a reader does not have to reconstruct it from the code. Naming matters because code is read far more often than it is written, and a bad name imposes that cost on every future reader including you.
What good names do:
Reveal intent. elapsedDays rather than d. The reader learns what it is without tracing where it came from.
Use domain vocabulary. If the business says "policyholder", the code should say policyholder, not user — because a mismatch between code and conversation forces continuous translation, and translation is where misunderstandings live.
Scale with scope. A loop index of two lines can be i; a field on a widely used class cannot. Short names are fine in short scopes and harmful in long ones.
Avoid encoding type in the name, which the type system already states and which becomes wrong after a refactor.
Distinguish meaningfully. getUserData, getUserInfo and getUserRecord in one codebase tell a reader nothing about which to call.
Read naturally at the call site, which is a better test than reading the declaration.
The specific failures:
Abbreviations that only the author expands.
Numbered variants — data2, processB — which signal that a distinction was never articulated.
Lies. A name that no longer matches behaviour after a change is worse than no name, because readers trust it.
Negated booleans, where isNotDisabled produces double negatives at every use.
Vague nouns — data, info, manager, handler, helper — which frequently indicate that the thing has no clear responsibility. The naming difficulty is the signal, not the problem.
Why it matters beyond readability. A name you cannot choose usually means a concept you have not identified, and a class you cannot name usually does more than one thing. Naming trouble is design feedback, which is the most useful thing about it.
Rename freely. Modern tooling makes it safe, and stale names persist mostly through timidity.