← Blog · April 19, 2026 · ConvertCaseHQ Team · 6 min read

camelCase, snake_case, kebab-case: A Developer Cheat Sheet

Here's the short version. Types and classes get PascalCase in almost every language. Variables and functions get camelCase in JavaScript, Java, C#, Kotlin and Swift, but snake_case in Python, Ruby and Rust. Constants get SCREAMING_SNAKE_CASE in most languages, with Go, Swift, C# and Google-style C++ as the exceptions. Anything that ends up in a URL, a CSS file or a package name is usually lowercase kebab-case, and environment variables are uppercase with underscores.

That's the pattern. The details are where code reviews get argued, so this cheat sheet sticks to what each language's official or most widely used style guide actually says, and names the source for every language.

camelCase, snake_case, kebab-case: the five styles and their other names

• camelCase (orderTotal): first word lowercase, every later word capitalized. Also called lowerCamelCase; PEP 8 calls it mixedCase.
• PascalCase (OrderTotal): every word capitalized. Also UpperCamelCase, CapWords (PEP 8) or StudlyCaps (PHP's PSR-1).
• snake_case (order_total): lowercase words joined by underscores.
• SCREAMING_SNAKE_CASE (ORDER_TOTAL): uppercase words joined by underscores. Google's JavaScript guide calls it CONSTANT_CASE and its Java guide UPPER_SNAKE_CASE.
• kebab-case (order-total): lowercase words joined by hyphens. Most languages can't use it for identifiers, because the hyphen is a minus sign.

To switch a name between styles, paste it into our case converter. It splits on spaces, underscores, hyphens and existing capitals, so order_total, order-total and OrderTotal all convert cleanly into each other. Do one name at a time, though: it treats everything in the box as a single identifier.

Cheat sheet: naming conventions by language

A few rows need a footnote. In Go, the first letter isn't a style choice at all: it's the visibility rule. Area is exported from its package and area isn't, and the compiler enforces it. C++ has no language-wide convention; the standard library itself uses snake_case (std::unordered_map, push_back), so treat the Google row as one well-documented option, not the rule.

Rust is unusually strict about style. The compiler warns out of the box: write fn GetUser() or struct user_account and rustc suggests get_user and UserAccount before you've run a linter.

File, module and package names

• Java: a public top-level class must live in a file with exactly its name, capitals included. OrderService goes in OrderService.java, and javac rejects anything else.
• Kotlin: a file holding one class is named after that class. Other files get a descriptive UpperCamelCase name, such as ProcessDeclarations.kt.
• Python: modules get short, all-lowercase names, with underscores if they help readability. Packages should be short and lowercase too, and PEP 8 discourages underscores in them.
• Ruby: snake_case files named after the class inside, so HelloWorld lives in hello_world.rb.
• Go: package names are lowercase single words with no underscores or mixedCaps: base64, not encoding_base64 or encodingBase64.
• JavaScript and TypeScript: no single rule. Google's JavaScript guide wants all-lowercase file names with underscores or dashes, and its TypeScript guide uses snake_case. Airbnb's guide says a file name should match its default export, so a CheckBox class lives in CheckBox.js. Pick one per project and write it down.
• npm packages: new package names can't contain uppercase letters at all.

Beyond source code: env vars, CSS, HTML, URLs, JSON and SQL

One quirk on environment variables: POSIX says the standard utilities use uppercase names and reserves names containing lowercase letters for applications, so a lowercase name can never clash with a standard one. Uppercase is still the established habit, so we'd keep it and add a distinctive prefix (MYAPP_TIMEOUT) to avoid clashes instead.

The CSS and SQL rows each have a post of their own: see CSS naming and BEM for class names, and SQL naming conventions for why databases push you toward lowercase.

Acronyms: where the style guides disagree

Every guide agrees on userName. They split on userID. Google's JavaScript and Java guides lowercase acronyms like ordinary words (xmlHttpRequest, customerId). Go keeps each acronym in one case (ServeHTTP, appID). Microsoft's .NET guidelines capitalize both letters of a two-letter acronym (IOStream) but only the first letter of longer ones (HtmlTag). Rust treats them as words (Uuid), and PEP 8 prefers HTTPServerError to HttpServerError. We compare the options side by side in camelCase vs. PascalCase.

How to choose when you're not sure

1. Check whether the platform decides for you. CSS property names, Java file names, Go's exported names and React component names (which must start with a capital letter) aren't style choices.
2. Follow the language's official guide. New code should look like the standard library it sits next to.
3. Match the existing project. PEP 8 says it plainly: consistency within a project matters more than consistency with the style guide.
4. Let a linter remember it. ESLint's camelcase rule, Ruff's N rules for Python and rustc's built-in warnings catch slips before a reviewer has to.
5. Convert once at the boundary. When snake_case JSON meets camelCase JavaScript, rename the keys in one serialization layer instead of letting both styles leak through the codebase.