Naming Conventions: camelCase vs snake_case vs kebab-case

If you have ever wondered why JavaScript variables look like userName, Python variables look like user_name, and CSS classes look like user-name, you have bumped into the world of naming conventions. Each programming ecosystem settled on a different case format for historical and ergonomic reasons, and working across ecosystems means converting between them constantly. This article explains the common conventions, when each is appropriate, and how to convert between them without breaking acronyms.

The common case formats

• camelCase — first word lowercase, subsequent words capitalized: userLoginCount. Standard for variables and functions in JavaScript, Java, Swift, and Go.
• PascalCase (a.k.a. UpperCamelCase) — every word capitalized: UserLoginCount. Used for class names, type names, and React components.
• snake_case — words separated by underscores: user_login_count. Standard in Python, Ruby, Rust, and SQL identifiers.
• kebab-case — words separated by hyphens: user-login-count. Used in CSS class names, URLs, file names, and command-line flags.
• CONSTANT_CASE (a.k.a. SCREAMING_SNAKE_CASE) — uppercase with underscores: USER_LOGIN_COUNT. Used for constants and environment variables.
• Title Case — every major word capitalized with spaces: User Login Count. Used in headlines and titles.
• Sentence case — first word capitalized, rest lowercase: User login count. Used in body text.
• UPPERCASE / lowercase — every letter the same.

You can convert any text between all nine with the Case Converter.

Why each ecosystem chose its convention

Conventions are not arbitrary — they solve real problems.

camelCase in JavaScript

JavaScript inherited camelCase from Java, which inherited it from Smalltalk and C conventions. camelCase is compact (no extra separator characters), readable, and works in contexts where hyphens are illegal (variable names cannot contain - in most languages). The lowercase first letter distinguishes a variable (userLoginCount) from a class (UserLoginCount), which is a useful signal at a glance.

snake_case in Python

Python’s PEP 8 style guide mandates snake_case for variables and functions. snake_case is slightly more readable than camelCase for long names (user_login_count vs userLoginCount) because the underscores create clear word boundaries. It also reads more naturally to non-programmers. Ruby, Rust, and SQL followed the same convention.

kebab-case in CSS and URLs

CSS chose kebab-case (user-login-count) because hyphen-separated class names are unambiguous in selectors and because hyphens are legal in CSS identifiers. URLs use kebab-case because hyphens are the only separator Google treats as a word boundary — user-login-count is read as three words by the search engine, while user_login_count is read as one. File names and CLI flags use kebab-case for the same reason: hyphens are safe in URLs and shells, and visually distinct from underscores.

CONSTANT_CASE for constants

Environment variables and constants use CONSTANT_CASE to make them stand out from regular variables. MAX_CONNECTIONS is clearly a constant; maxConnections could be a variable that changes.

When to use which

Context	Convention	Example
JavaScript / TypeScript variables	camelCase	userLoginCount
JavaScript / TypeScript classes, React components	PascalCase	UserLogin
Python, Ruby, Rust variables and functions	snake_case	user_login_count
SQL identifiers	snake_case	user_login_count
CSS class names	kebab-case	user-login-count
URL slugs	kebab-case	/blog/user-login-count
File names	kebab-case or snake_case	user-login-count.md
Constants and env vars	CONSTANT_CASE	MAX_CONNECTIONS
Headlines and titles	Title Case	User Login Count

Converting between formats

The hard part of conversion is splitting the input into words. A good converter treats three things as word boundaries:

1. Explicit separators — spaces, hyphens, and underscores.
2. Case transitions — the boundary between a lowercase letter and an uppercase letter (userLogin → user, Login).
3. Acronym boundaries — a transition from uppercase to uppercase-then-lowercase (URLParser → URL, Parser).

Once the words are split, re-joining is straightforward: lowercase each word, then apply the target format’s rules (capitalize first letter for camelCase/PascalCase, join with _ for snake_case, join with - for kebab-case, uppercase everything for CONSTANT_CASE).

The acronym problem

Acronyms are the tricky case. URLParser could be converted to:

• urlParser (camelCase) — the conventional JavaScript form
• url_parser (snake_case) — the conventional Python form
• UrlParser (PascalCase)

But a naive converter that lowercases everything might produce urlparser, losing the word boundary between URL and Parser. This is why acronym-heavy identifiers often need manual review after conversion. The Case Converter splits on case transitions, so URLParser becomes URL + Parser and converts correctly to url_parser and url-parser. For identifiers that must preserve acronym casing in the output, adjust manually after conversion.

Consistency matters more than the choice

The specific convention you pick matters less than applying it consistently. A codebase that mixes userLoginCount, user_login_count, and user-login-count is harder to read than one that picks a single convention and sticks to it. Enforce the convention with a linter (ESLint, flake8, rustfmt) and a formatter (Prettier, Black) so the decision is made once and applied automatically.

When you need to convert identifiers in bulk — say, when porting a JavaScript API to Python, or generating CSS class names from a design token list — run them through the Case Converter and review the acronym cases. It is faster and more reliable than renaming by hand, and it keeps your identifiers consistent across every ecosystem you work in.