Common bad naming patterns and how to fix them

Knowing what not to do is as important as knowing best practices. These four antipatterns appear constantly in codebases of all sizes and kill readability immediately.

Magic numbers — raw numbers embedded in logic with no explanation.

// Bad — what is 86400? What is 3?
if (sessionAge > 86400) expireSession();
if (retries > 3) throw new Error();

// Good — the name explains the rule
const SECONDS_PER_DAY = 86400;
const MAX_RETRY_ATTEMPTS = 3;

if (sessionAge > SECONDS_PER_DAY) expireSession();
if (retries > MAX_RETRY_ATTEMPTS) throw new Error();

Hungarian notation — prefixing names with type information: strName, intCount, bIsActive. Modern IDEs and typed languages already tell you the type. Don't duplicate it in the name.

Noise words — theUser, aProduct, userData, infoList. Strip the noise: user, product, users.

Misleading names — the most dangerous antipattern. A name that implies one behavior but implements another.

// Extremely dangerous — name says get, code deletes
function getInactiveUsers() {
  db.users.deleteWhere({ active: false }); // !!
  return [];
}

Audit your codebase for these four patterns regularly. Rename freely — refactoring a name is the safest refactor you can make, and modern IDEs do it in one click. There is no excuse to live with a bad name after you've identified it.

If you cannot think of a good name within two minutes, write a comment describing what the thing does. That comment is your name, just in disguise.