Fetch note: Direct retrieval of this page was blocked by the network egress proxy (kolemannix.com is not reachable via WebFetch in this environment), and archive.org was also unreachable. The content below was reconstructed from verbatim quotes and paraphrased passages surfaced via web search, not captured as a single continuous fetch. It should be treated as a faithful partial excerpt rather than the complete original text — see the source URL for the full essay.

How to Name Things

by Koleman Nix

Naming is communication, and clear language entails clear thinking. We name many things in software: a local variable, a function, a field on a struct, an API endpoint, an application page, a database table or its columns, the product itself. Every time we do, we’re communicating — with our colleagues, with our future selves, and now with language models — through that name.

The piece pushes back on a common misconception: that consistency in naming is a virtue in itself. Naming decisions should take in as many inputs as possible — not just the type of a thing and its current, narrow usage, but the full context of what it means. Poor naming degrades a codebase for humans and LLMs alike.

On database columns: for a column holding the date something began to exist, created_at is a reasonable default — the at suffix acting as a preposition of time — while created_on fits better when the column holds a date rather than a timestamp. The right choice depends on what the row and column actually mean, not a fixed rule applied blindly.

On function names and call sites: a function’s name should reflect its essential purpose, not every specific use case. If a function converts from reals to integral pixels, that particular narrative (e.g. why you’re converting, for what usage) doesn’t need to be baked into the function’s own name — that story belongs at the call site, told through the local variable names surrounding the call.

On DRY: DRY, understood properly, says that a fact should be expressed in exactly one place, and that if two pieces of code express the same fact, they should point at the same place — naming is part of enforcing that discipline.

On naming hard cases (e.g. an optional variable): the essay argues you can’t shortcut this by convention alone — “the answer is to buckle up and engage deeply; to read the code from the top, in your head, pretending to be your teammate. Then ruminate on this variable and its properties.” It poses the kind of questions that should drive the name: “Is it always optional? Is it optional only because its absence is an error, in which case perhaps we should handle that error earlier, or name the variable in a way that says so? Is it a fallback? Is it a set of overrides?”

(This excerpt is assembled from search-indexed fragments of the original post. For the complete essay with all examples and surrounding argument, see the source link above.)