There's an old joke, usually credited to Phil Karlton: there are only two hard things in computer science, cache invalidation and naming things. Developers have since added a third: off-by-one errors.

We laugh, and then we open a file and find $data2. Written by us. Last Tuesday.

So let's take a short tour of the naming hall of fame. You'll recognise most of the exhibits. Some of them you've probably committed.

The exhibits

❌ $data, $data2, $newData. Everything in a program is data. Calling a variable $data is like labelling a moving box "stuff". And $data2 tells you only that someone ran out of ideas after $data.

❌ $temp. Temporary, it promised. It has now survived three refactors, two framework upgrades and a change of team.

❌ report_final_FINAL_v3_fixed.php. Version control exists so this file doesn't have to. If you see it in a repository, someone was scared of Git, and possibly still is.

❌ handleStuff(), processData(), doIt(). Functions that do something. To something. For reasons.

❌ Helper, Utils, Manager. The junk drawer of class names. StringHelper starts with one method and ends up holding date formatting, a currency converter and a function that sends Slack messages.

❌ $isNotDisabled. Now write if (! $isNotDisabled) and see how long it takes your brain to land. Double negatives are a tax on every reader, forever.

❌ $timeout = 30. Thirty what? Seconds? Milliseconds? Minutes? Somebody will guess wrong, and they'll guess wrong in production.

❌ $usr, $cstmr, $amt. Vowels are free. They have always been free.

❌ The liar. A function called getUser() that also updates the last-login time, sends an analytics event and occasionally creates the user if it doesn't exist. The name is a promise, and this one is broken.

Why it's actually hard

Naming isn't hard because we're lazy. It's hard because a good name requires you to know exactly what the thing is. When you can't name a function, it's often because it does two things. When you can't name a variable, you might not be sure yet what it holds.

That's the useful secret: a bad name is often a design smell, not a vocabulary problem. processData() is hard to name because it's doing validation, saving and emailing at once. Split it, and the names write themselves: validateInvoice(), saveInvoice(), sendInvoiceEmail().

Rules that actually help

✅ Name by role, not by type. $overdueInvoices, not $invoiceArray. The type changes; the meaning doesn't.

✅ Booleans read as yes/no questions. $isActive, $hasSignedContract, $canApprove. Then if ($tenant->hasSignedContract) reads like a sentence.

✅ Put the unit in the name. $timeoutSeconds, $amountInCents, $maxFileSizeMb. One word prevents a whole category of bugs.

✅ Functions are verbs, and the verb should be honest. get means no side effects. If it creates or changes something, say so: findOrCreateUser(), recordLogin().

✅ Name length follows scope. $i is fine in a three-line loop. A class property that lives for years deserves a full, descriptive name.

✅ Pick one word per concept. If the codebase says tenant, don't introduce renter, occupant and resident for the same thing. Use the words your users and business use, so code and conversations match.

✅ Rename without fear. Modern editors rename safely across a project in seconds. A bad name you're "used to" is still a bad name for the next person.

A small confession

I still write $temp sometimes, usually at the end of a long day when I just need the code to run. The trick isn't never doing it. It's catching it before the pull request. These days I read my own diff once just for names, and it's one of the cheapest quality checks I know.

AI assistants help here too, as long as you ask. "Suggest clearer names for the variables in this function" is a great prompt, and it costs nothing to ignore the bad suggestions.

What's the worst variable or function name you've ever found in a codebase? Bonus points if you wrote it yourself.