camelCase, snake_case, and kebab-case in practice
Which convention belongs where, how to handle a project that needs several at once, and why acronyms cause trouble.
Why several conventions exist
Programming languages generally forbid spaces in identifiers, so any name made of more than one word needs a way to mark the boundaries.
Marking with capital letters gives camelCase and PascalCase, marking with underscores gives snake_case, and marking with hyphens gives kebab-case. Technically any of them works, but each language community settled on conventions over time, and following them is what makes code read naturally.
Which convention goes where
These are the conventions in widest use by language and context.
- camelCase: variables and functions in JavaScript and Java, as in userName or getTotalPrice.
- PascalCase: classes and components across most languages, including React components.
- snake_case: variables and functions in Python and Ruby, and most database column names.
- kebab-case: CSS classes, URL paths, HTML attributes, and filenames. Hyphens are not valid in identifiers in most languages, so this lives outside code.
- CONSTANT_CASE: constants and environment variables, such as MAX_RETRY_COUNT or DATABASE_URL.
When one project needs several
Real projects carry several conventions at once: snake_case database columns, camelCase JavaScript, and kebab-case CSS all describing the same concept.
What matters is making the boundary explicit. Decide on a single layer where conversion happens and the confusion largely disappears. Usually that is the data access or serialization layer, converting once so the application interior uses one convention throughout.
Many ORMs and serialization libraries offer this conversion as an option. Automatic conversion can surprise you with acronyms, though, so check the real output before relying on it.
The acronym problem
Acronyms such as ID, URL, HTTP, and API make word boundaries ambiguous, and tools disagree about them.
Converting userID to snake_case may produce user_id or user_i_d. HTTPRequest may become http_request or h_t_t_p_request.
The way out is to treat acronyms as ordinary words from the start. Writing userId and HttpRequest, capitalising only the first letter, is widely adopted and is what the official Java and Kotlin style guides recommend.