The art of naming: why naming is applied philosophy

There’s an old joke in the trade: there are only two hard problems in programming —cache invalidation, naming things, and off-by-one errors. The punchline is the miscount, but the truth is in the second problem. Naming well is hard because it isn’t a matter of style. It’s a decision about what each thing is.

Naming draws a border

When you call something user, you’re claiming it is a user and not an account, a profile, a session, or a contact. The word carves up the world. And the cut you make while naming propagates: everyone who reads that name will think inside the border you drew, even if the border was in the wrong place.

That’s why a bad name isn’t cosmetic. It’s a false hypothesis embedded in the code, inherited by others without them noticing.

Frege: sense and reference

Gottlob Frege distinguished between the reference of a name (what it points at) and its sense (how it presents it). “The morning star” and “the evening star” point at the same planet, Venus, but present it differently.

Code works the same way. getUser() and fetchAccount() can return the same record from the same table —same reference— and still tell different stories about what that data is for. Sense matters as much as reference, because sense is what the next developer will believe.

A name lies when its sense doesn’t match what the function actually does. A validate() that also writes to the database isn’t a poor name: it’s a lying name.

Wittgenstein: meaning is use

The later Wittgenstein dismantled the idea that words have a fixed meaning glued behind them. The meaning of a word, he said, is its use within a practice.

Applied to code: a name doesn’t mean what the dictionary says, nor what you had in your head when you wrote it. It means how it’s used across the hundred calls scattered through the project. If count is sometimes a total and sometimes an index, its real meaning is the confusion it causes, not the intention you baptized it with.

Hence an honest rule: a name is validated by whoever reads it, not by whoever wrote it. If you have to open the implementation to learn what a variable holds, the name already failed, however elegant it looks.

Naming is the last stage of understanding

Here’s the uncomfortable part. When you can’t find a good name, it’s almost never a vocabulary problem. It’s that you don’t yet understand what the thing is.

The elusive name is a symptom. data, info, manager, helper, process, handle —generic names are the residue of a concept you never finished thinking through. Giving them a concrete name forces you to decide what they are, and sometimes that decision reveals the design was badly split: that manager was doing three things that should live in three places.

That’s why naming isn’t done at the end, like painting a wall. It’s done by thinking, and the good name usually arrives together with the good structure. If the name won’t come, it’s not that you lack creativity: it’s that the problem isn’t solved yet.

Practical rules I use

• Name by what it is, not by how it’s implemented. orderedItems survives a change of structure; arrayList dies with it.
• One name, one concept. If the same word means two things in two modules, you have two concepts disguised as one.
• Length pays when life is long. A three-line variable can be called i. A domain concept read a hundred times deserves to be spelled out.
• Distrust convenient names. utils, common, misc are drawers where judgment goes to die. What you don’t know where to put is what you don’t yet understand.
• Read it out loud. If saying the call doesn’t make sense as a human sentence, the name is lying somewhere.

Why it matters to me

I wrote philosophy before I wrote code, and the bridge between the two disciplines is exactly this: language doesn’t describe the world, it carves it up. Choosing a word is choosing which distinctions you’ll see and which you’ll render invisible.

A program is, at bottom, a theory about a slice of the world written in names. If the names are honest, the theory can be read, argued with, and corrected. If the names lie, every line resting on them inherits the lie.

Naming well isn’t cosmetics. It’s the cheapest way to think clearly —and the only one that also stays written down.