Naming

Naming is where bugs hide. These are the conventions I’ve found earn their keep — not from a style guide, from cleaning up code that broke because a name lied.

Boolean prefixes: is, has, can — and check for functions

Variables get is / has / can. Functions that return a boolean get check. This is not aesthetic; it’s collision-prevention.

const isValid = checkIsValid(input)   // no shadowing, both read cleanly

Without the split, you get const isValid = isValid(input) and a type-error hunt three weeks later when someone renames one of them.

Transformers name the target, not the journey

toDollars(price)          // good
fromEurosToDollars(price) // the "from" is already in the argument's type

Every extra word in a name is a reader tax. If the source is obvious from the input, don’t repeat it in the name.

Regex names carry their role

const emailValidator = /.../
const phoneMatcher = /.../
const whitespaceSplitter = /.../
const currencyReplacer = /.../

Not emailRegex. A regex is a tool; the name should say what job it does. Two months later, emailRegex requires reading the regex to know if it validates, extracts, or replaces. emailValidator doesn’t.

This is a personal convention — I haven’t seen it enforced elsewhere. Borrow if it clicks.

Constants means “truly invariant”

PI, MAX_UPLOAD_SIZE_MB. Not the current copy of a marketing string, not this quarter’s tax rate. If it changes based on environment, tenant, or business decision, it’s config, not a constant. Putting it in constants.ts teaches the next dev to hardcode the next one too.

Props go in a Props type, not an I-prefixed interface

type UserCardProps = { user: User; onEdit: () => void }

Not IUserCardProps. The I prefix survived from a world where you couldn’t tell a class from an interface at a glance; TypeScript’s tooling has told you that for a decade. Delete the noise.

---

Everything else — camelCase vs. snake_case, function-declaration vs. arrow, tabs vs. spaces — I don’t care, as long as the linter is authoritative and the whole repo agrees. Fights about those are how teams avoid having harder conversations.