Case conventions look like bikeshedding until you work in a codebase where nobody agreed on one. Then a search for getUserId misses get_user_id, a CSS class silently fails to match, and a URL that worked on your laptop returns 404 on the server. The conventions exist because the alternative costs real time.
The Six You Will Actually Meet
Each convention solved a specific problem when it was introduced, and most are still in use for that reason.
camelCase
First word lowercase, every following word capitalised: userAccountId. Standard for variables and functions in JavaScript, Java, Swift and C#. It reads quickly at a glance and costs no extra characters.
PascalCase
Every word capitalised, including the first: UserAccountId. Reserved almost universally for types, classes and components. The distinction from camelCase is what lets you tell a class from a variable without context.
snake_case
All lowercase, underscores between words: user_account_id. The convention in Python, Ruby, Rust and most SQL databases. Easier to read for long names, which is why it dominates where names get descriptive.
kebab-case
All lowercase, hyphens between words: user-account-id. Required in URLs and CSS class names because both treat the hyphen as an ordinary character while underscores can be awkward. Never valid as an identifier in most languages, since the hyphen parses as subtraction.
SCREAMING_SNAKE_CASE
All uppercase with underscores: MAX_RETRY_COUNT. Signals a constant in nearly every language, and the standard for environment variables everywhere.
Title Case
Capitalised words for prose headings: Which Case Goes Where. Not a programming convention at all, and the rules differ by style guide, which is the source of most disagreement about it.
What Each Language Expects
Following the local convention matters more than any argument about which is better. Consistency with the ecosystem beats personal preference.
| Context | Variables and functions | Types and classes | Constants |
|---|---|---|---|
| JavaScript / TypeScript | camelCase | PascalCase | SCREAMING_SNAKE |
| Python | snake_case | PascalCase | SCREAMING_SNAKE |
| Ruby | snake_case | PascalCase | SCREAMING_SNAKE |
| Go | camelCase (private) | PascalCase (exported) | PascalCase or camelCase |
| Rust | snake_case | PascalCase | SCREAMING_SNAKE |
| Java / C# | camelCase | PascalCase | SCREAMING_SNAKE |
| SQL | snake_case | snake_case | n/a |
| CSS | kebab-case | kebab-case | kebab-case (custom properties) |
| URLs and file paths | kebab-case | kebab-case | n/a |
| Environment variables | SCREAMING_SNAKE | n/a | SCREAMING_SNAKE |
The Case That Changes Behaviour
In most languages, case is a convention you can break without consequence beyond annoying your colleagues. Go is the exception worth knowing about.
In Go, capitalisation controls visibility. An identifier starting with an uppercase letter is exported from its package and visible to other packages. A lowercase one is not. Renaming `userCount` to `UserCount` does not just change style, it changes the public API of your package.
This catches people who arrive from languages with explicit `public` and `private` keywords, because nothing in the syntax announces that a capital letter is doing access control. If a Go symbol suddenly stops compiling elsewhere after a rename, this is almost always why.
Title Case rules are not universal
AP style capitalises words of four letters or more, so it writes "Which Case Goes With Data". Chicago capitalises all words except articles, coordinating conjunctions and prepositions regardless of length, giving "Which Case Goes with Data". Neither is wrong. Pick one, write it into your style guide, and stop relitigating it in code review.
The Acronym Problem
Every convention breaks down on acronyms, and every large codebase has an inconsistent mix as a result.
Is it `parseHTTPResponse` or `parseHttpResponse`? Is the identifier `userID` or `userId`? Both appear in major standard libraries, sometimes in the same one.
The rule that causes least trouble is to treat acronyms as ordinary words: capitalise only the first letter, giving `parseHttpResponse` and `userId`. This keeps case conversion reversible, which matters more than it sounds. A tool converting `userID` to snake_case has to guess whether you meant `user_i_d` or `user_id`, and it will sometimes guess wrong. `userId` converts to `user_id` unambiguously every time.
Google's Java style guide and Microsoft's .NET guidelines both landed on this rule for the same reason. The exception is Go, whose own conventions keep acronyms fully capitalised, so `userID` is idiomatic there.
Convert between cases instantly
UPPER, lower, Title, Sentence, camelCase, snake_case and kebab-case.
Why URLs Use Hyphens
Google has stated directly that hyphens are treated as word separators in URLs while underscores are not, or at least not reliably. A page at `/word-counter-guide` is understood as three words. The same path with underscores has historically been read as one long token.
The practical difference is smaller than it was, because modern search engines handle both better than they did in 2010. But hyphens remain the safer choice, they read better to humans scanning a URL, and every major CMS defaults to them. There is no upside to underscores in a path.
Case matters here too. Paths on Linux servers are case-sensitive, so `/About` and `/about` are different pages. Serving both is a duplicate content problem, and linking to one while your canonical points at the other quietly splits your ranking signals. Lowercase everything and redirect the variants.
Frequently Asked Questions
Related Tools
Keep Reading
Word Count Targets: What Editors, Platforms and Google Expect
Two counters can disagree by five percent on the same paragraph. Here is how counting actually works, and the targets worth writing to.
JSON Errors Explained: Trailing Commas, NaN and Other Rejections
Why valid-looking JSON fails to parse, how to read a parser's error position, and the number precision bug that silently corrupts large IDs.
URL Encoding: encodeURI vs encodeURIComponent, and the Plus Sign
The two JavaScript functions are not interchangeable, and picking the wrong one is the most common URL bug there is. Plus where %2520 comes from.
Lorem Ipsum: The 2,000-Year-Old Text Hiding in Your Mockups
It is a scrambled passage of Cicero from 45 BC. Why fake Latin beats real English for layout work, and the design problems it quietly hides.