Reserve
Reserved words are one of those problems you only notice when you ship: everything works locally, then a deploy fails, a migration blows up, or your config parser starts behaving oddly.
This page is a quick field guide to naming pitfalls and how to avoid them — especially in places where names become part of an API: URLs, database columns, JSON keys, environment variables, and config files.
What “reserved” actually means
A word can be “reserved” in a few different ways:
- Language keywords (e.g.
class,switch,yield) that can’t be used as identifiers. - Platform-reserved names (historically on Windows:
CON,PRN,AUX,NUL, etc.) that can cause file operations to fail. - Framework conventions where certain keys carry special meaning.
- Protocol and header names that are technically allowed but practically unsafe.
The tricky part is that the failure mode is often indirect: a word might be fine in your app code, but not in the place it ends up being serialized.
Common naming footguns
1) URLs and route segments
Short words are tempting because they look clean: /new, /admin, /api, /login.
But these are also the paths that:
- collide with existing middleware,
- conflict with reverse proxies,
- or end up treated specially by security tooling.
If you want a stable public path, prefer something descriptive and unlikely to collide, like /account-settings instead of /settings.
2) Database columns
Databases each have their own reserved words, and ORMs add another layer of convention.
If you’re naming columns, avoid terms that are often special:
order,group,user,index,limit,references
It doesn’t mean they’re always forbidden — it means they’re costly when they break.
3) Environment variables and config keys
Config keys are where reserved words hurt most, because they get copied between systems.
A simple rule that works well:
- Use a clear prefix:
APP_,SITE_,DEPLOY_. - Use uppercase with underscores for env vars.
- Keep keys stable once published.
Practical patterns that avoid pain
Use explicit namespaces
Instead of PORT, use APP_PORT.
Instead of TOKEN, use CF_API_TOKEN or GITHUB_TOKEN.
It’s not stylish, but it prevents collisions.
Prefer descriptive names over “cute” ones
The best names are boring. If a name is “cute”, it’s usually ambiguous.
Document the public contract
If a name is used externally (a URL, a webhook field name, a CLI flag), treat it like an API: write it down, and don’t change it casually.
For web platform behaviour, MDN is a solid baseline reference: https://developer.mozilla.org/
Quick links
- Tools note: /release1-2-tools.html
- Phishing basics: /security/phishing/
Closing thought
If you’re unsure whether a name is safe, choose the slightly longer, more specific option. It’s a small cost up front, and it prevents the kind of bugs that only show up when everything is on fire.