camelCase, snake_case, kebab-case: which naming convention goes where

Programmers spend a surprising amount of time on capitalization. Variable names, file names, database columns, and URLs all follow different conventions, and mixing them up can cause anything from inconsistent code to broken links. Here's what each common case style is, where it's used, and why the conventions exist.

The main styles

• camelCase: words joined together, first word lowercase, each later word capitalized: userAccountId.
• PascalCase: like camelCase, but the first word is capitalized too: UserAccount. Also called UpperCamelCase.
• snake_case: all lowercase, words separated by underscores: user_account_id.
• kebab-case: all lowercase, words separated by hyphens: user-account-id. Also called dash-case.
• CONSTANT_CASE: all uppercase, words separated by underscores: MAX_RETRY_COUNT. Also called SCREAMING_SNAKE_CASE.

Where each one is used

Conventions come from language communities and their style guides:

• JavaScript and TypeScript: camelCase for variables and functions, PascalCase for classes and React components, CONSTANT_CASE for fixed constants.
• Java and C#: camelCase for variables and methods in Java, PascalCase for classes in both; C# also uses PascalCase for methods and properties.
• Python: snake_case for variables and functions, PascalCase for classes, CONSTANT_CASE for constants, as described in the PEP 8 style guide.
• Ruby and Rust: snake_case for methods and variables, PascalCase for types.
• Go: camelCase or PascalCase, where the capitalization itself has meaning: names starting with a capital letter are exported from a package.
• SQL databases: snake_case is the most common convention for table and column names, partly because many databases fold unquoted identifiers to a single case.
• CSS and HTML: kebab-case for class names, IDs, and custom properties.
• URLs and file names: kebab-case is favored for URLs because hyphens are treated as word separators by search engines and are easy to read.
• Environment variables: CONSTANT_CASE, like DATABASE_URL.

Why kebab-case can't be a variable name

In most programming languages, a hyphen is the minus operator, so user-name would be read as user minus name. That's why kebab-case shows up in places that aren't code identifiers, like URLs, CSS, and command-line flags, while code uses camelCase or snake_case.

Acronyms: HTMLParser or HtmlParser?

Style guides disagree. Some keep acronyms in capitals (XMLHttpRequest in the web platform mixes both). Many modern guides, including Microsoft's .NET guidelines for longer acronyms and Google's Java style guide, recommend treating acronyms as normal words (HtmlParser, userId), because consecutive capitals make word boundaries hard to see. Whichever you choose, consistency within a project matters most.

Converting between them

Converting is common when data crosses a boundary: a Python backend with snake_case fields talking to a JavaScript frontend that expects camelCase, or turning a page title into a kebab-case URL slug. Most frameworks have serializers that handle this automatically for API data. For one-off conversions, the case converter handles all of these styles. It treats runs of letters and numbers as words and everything else as separators, so "User Account ID" becomes userAccountId, user_account_id, or user-account-id in one step.

Consistency beats preference

There's no objectively best naming style. The best choice is whatever your language, framework, and team already use. Following the established convention makes code easier to read for everyone who works on it later, and linters can enforce it automatically.