camelCase vs snake_case vs kebab-case: who uses what?
Naming conventions are tribal knowledge with real consequences: mixing them breaks linters, confuses APIs, and produces inconsistent code. Each convention dominates a specific layer of the stack.
How conversion works
Converting between cases means splitting text into words first. A good
tokenizer handles spaces, hyphens, underscores, and camelCase boundaries
alike—so parseHTTPResponse, parse_http_response,
and parse http response all reduce to the same three words.
Where each convention lives
Follow the ecosystem you are writing for.
| Convention | Example | Typical habitat |
|---|---|---|
| camelCase | userAccountName | JavaScript variables and functions, Java methods, JSON keys in many APIs |
| PascalCase | UserAccountName | Class names, UI components, exported types |
| snake_case | user_account_name | Python, Ruby, Rust, SQL columns, database fields |
| kebab-case | user-account-name | CSS classes, URLs, slugs, HTML attributes, file names |
| CONSTANT_CASE | MAX_RETRIES | Environment variables and compile-time constants |
Rules of thumb
Match the host language
The language or framework decides, not personal taste. Lint rules exist so reviewers argue about ideas instead of underscores.
Pick one wire format
If your backend speaks snake_case JSON and your frontend prefers camelCase, convert at exactly one boundary rather than letting both forms leak everywhere.
Decide how to treat them
Treat acronyms as ordinary words or keep them fully upper—either is fine as long as the choice stays consistent across the codebase.