camelCase vs snake_case vs kebab-case: which naming style where

Code names cannot contain spaces, so programmers join words in several ways: userName, user_name, user-name, UserName, USER_NAME. None is better in general. Each language and context has a convention, and following it makes code easier to read and avoids bugs.

The styles

Where each is used

• JavaScript and TypeScript: camelCase for variables and functions, PascalCase for classes and React components, CONSTANT_CASE for fixed constants.
• Python: snake_case for variables and functions, PascalCase for classes, CONSTANT_CASE for constants, as set out in the PEP 8 style guide.
• Java, C# and Kotlin: camelCase for variables and methods (PascalCase for methods in C#), PascalCase for types.
• CSS: kebab-case for property names and usually for class names, such as font-size and .nav-link.
• URLs and file names: kebab-case. Google's guidance recommends hyphens rather than underscores to separate words in URLs.
• SQL databases: snake_case for tables and columns, because many databases are case-insensitive or fold case.
• Environment variables: CONSTANT_CASE, such as DATABASE_URL.
• JSON APIs: varies. JavaScript-heavy APIs tend to use camelCase; many others use snake_case. Pick one per API and never mix them.

Why kebab-case cannot be used everywhere

In most programming languages, a hyphen is the minus sign, so order-total means “order minus total”. That is why kebab-case lives in CSS, URLs, file names and HTML attributes, where hyphens are allowed, and not in variable names.

Convert between styles

Paste names or a list into the Case Converter and choose camelCase, PascalCase, snake_case, CONSTANT_CASE or kebab-case. It is handy when mapping database columns to object properties, turning headings into URL slugs, or renaming a batch of variables.

Mapping between layers

A typical web app meets several conventions at once: snake_case columns in the database, camelCase properties in JavaScript, kebab-case in URLs. Convert at the boundary, in one place, rather than letting both styles leak through the code. Most database libraries and serialisers can map order_total to orderTotal automatically; turn that on once and the rest of the code only ever sees one style.

Acronyms

Decide how to treat acronyms and be consistent: userId or userID, HttpClient or HTTPClient. Many style guides prefer treating acronyms as words (userId, HttpClient), because parseHTMLURL is hard to read.

Good names, not just good case

• Start booleans with is, has or can: isActive, has_paid.
• Use plurals for lists: orders, not orderList or order.
• Spell words out: customerAddress beats custAddr.
• Name functions with verbs: calculateTotal, send_invoice.
• Include units where they matter: timeoutMs, price_cents.

Consistency beats preference

When joining an existing project, follow its style even if you prefer another. Linters and formatters can enforce naming rules automatically. For capitalising headings in prose, see title case rules.