Clean code naming practices

Naming is the cheapest documentation you will ever write and the first thing the next reader sees. A good name removes the need for a comment.

Say what it is, not how it is stored

Name things after intent. activeUsers beats arr, isExpired beats flag.

// unclear
const d = users.filter((u) => u.a);

// clear
const activeUsers = users.filter((user) => user.isActive);

Make booleans read like questions

Prefix with is, has, can, or should so conditionals read like English: if (user.canEdit) reads better than if (user.edit).

Length should match scope

A loop index that lives for one line can be i. A value that lives across a whole module deserves a full, descriptive name. The wider the scope, the more the name has to carry.

Avoid noise words

UserData, UserInfo, and UserObject all mean the same thing as User. Words like Data, Info, Manager, and Helper often add characters without adding meaning.

Be consistent

Pick one term per concept and stick to it. If you fetch in one place, do not get, load, and retrieve elsewhere for the same operation. A reader should not have to wonder whether two different words mean two different things.

Functions are verbs, values are nouns

• calculateTotal(), sendEmail(), parseDate() for actions
• total, email, startDate for the things

The test

If you need a comment to explain what a variable holds, the name has already failed. Rename it and delete the comment.