Case isn't important until it suddenly is. A NotesApp imported as notesApp silently breaks. A user_id field looked up with userId returns undefined. A kebab-case URL that got quietly rewritten to snake_case costs you three months of inbound search traffic before anyone notices.
The choice between nine or ten case styles looks trivial. Until you misstep.
This is a short guide to when each style fits — and the one case you should never, ever use.
A brief, silly history
Most case styles are named after things they look like. camelCase has humps. PascalCase starts tall, named for Blaise Pascal and carried forward by Pascal-the-language. snake_case has underscores that slither between words. kebab-case looks like a skewer of letters.
SCREAMING_SNAKE_CASE is what happens when you type before finishing your coffee.
The names are silly. The rules aren't. Each style encodes a convention from a particular language or medium, and the convention exists for a reason. Use the one the ecosystem expects and nobody even notices. Use the wrong one and you spend an afternoon debugging a case-sensitivity bug on macOS that works fine on the CI Linux box.
The eight to know
1. UPPERCASE — for screaming, sparingly
Correct use: two-letter initialisms (US, UK, SQL, URL). Emphasis in otherwise-lowercase prose. The "I'M NOT YELLING, IT'S JUST MY KEYBOARD" joke.
Wrong use: paragraphs of it. Our eyes scan lowercase letters by their outline — ascenders and descenders give words a shape. All-caps letters are identical rectangles, which is why reading them is measurably slower.
2. lowercase — the humble form
Correct use: identifiers with no internal structure (id, name, url). URL paths. Hashtags. Stylistic brand names where the lowercase is the brand (e.e. cummings, bell hooks, figma).
Wrong use: sentence-starting positions in formal writing. Your reader trusts the capital.
3. Title Case — for editors
Correct use: book titles, article headlines in most US publications (The New Yorker, The Atlantic, the Times). Company and product names.
The subtle rule: short prepositions and articles stay lowercase. "The War of the Roses," not "The War Of The Roses." Style guides disagree on the cutoff — AP capitalises words of four letters or more; Chicago keeps most prepositions lower. Pick one and hold.
4. Sentence case — the modern default
Correct use: product UIs, Medium-era blog titles, UK broadsheets (the Guardian famously), push notifications, button labels.
It reads less formal, more quiet. Apple's Human Interface Guidelines recommend it for everything below a top-level title. Paul Graham capitalises essay titles this way. It's what you reach for when "Title Case" feels like it's trying too hard.
5. camelCase — JavaScript's native tongue
Correct use: JavaScript and TypeScript variables, methods, properties (userAge, getUserById). Java methods. Swift identifiers. JSON keys in most modern APIs.
Wrong use: file names on case-insensitive filesystems (macOS, Windows) — UserService.ts and userService.ts will sometimes be the same file, sometimes not, and you'll lose half a day to a deploy that works on your laptop and breaks in Docker. Prefer kebab-case for filenames; keep camelCase for the identifiers inside them.
6. PascalCase — tall and proper
Correct use: JavaScript/TypeScript class names, React / Vue / Svelte component names, C# everything. Types and interfaces in most languages.
The test: if it's a noun and you might new it or render it as <Thing />, it's PascalCase. User, InvoiceLine, Button.
7. snake_case — underscores, underbars, Python
Correct use: Python variables and functions. SQL column and table names. Shell environment variables (together with all-caps — see #9). YAML and TOML keys in many projects.
Wrong use: URLs. Search engines treat underscores as glue, hyphens as separators — /my_post looks like one long word to a crawler; /my-post looks like two. Anything headed for a URL should be kebab-case.
8. kebab-case — the web's favourite
Correct use: URL slugs, CSS class names, HTML IDs, file names for static assets, command-line flags. Increasingly popular for YAML / TOML keys.
Not used in most programming languages for identifiers — because - is already a subtraction operator and the parser can't tell them apart.
The shouting sensible
9. CONSTANT_CASE — environment variables, physics
Correct use: compile-time constants in most languages (MAX_LENGTH, PI, DEFAULT_TIMEOUT). Environment variables (DATABASE_URL, API_KEY). Python module-level constants.
Wrong use: mutable state. If it can change, it isn't a constant, and the uppercase is lying.
The one you should never, ever use
aLtErNaTiNg cAsE.
Correct use: none.
It's the "SpongeBob mocking" meme from 2017. Useful for conveying sarcasm in a tweet. Useless for code, identifiers, documentation, typography, accessibility, and search. Screen readers stumble. Grep stops working. Line breaks can hide the pattern. It has been, to date, the only case style that has actively made software worse at the companies I've worked in.
If you think you need it — and I say this with the confidence of someone who has watched a senior engineer commit it "as a joke" into the build system — you don't.
A small rule
When in doubt, look at the ecosystem you're writing for. JavaScript tutorials use camelCase; use camelCase. Python tutorials use snake_case; use snake_case. Rails uses both — snake_case in the models, camelCase in the views — and documents which goes where.
The goal is to disappear. Case is like typography: done well, the reader never notices.