camelCase vs snake_case: A Guide to Naming Conventions
Every programmer eventually argues about naming conventions, and the argument is never really about aesthetics. Conventions exist because consistent naming makes code scannable, and because most languages have a house style that the entire ecosystem already follows.
Here is what each convention is called, which languages expect which, where the names came from, and how to convert between them without doing it by hand.
The five conventions
camelCase joins words with no separator and capitalises every word except the first: userAccountName. The name comes from the humps. PascalCase does the same but capitalises the first word too: UserAccountName, named after the Pascal language. snake_case uses lowercase words joined by underscores: user_account_name. kebab-case uses hyphens: user-account-name, named for words skewered on a stick. CONSTANT_CASE — also called SCREAMING_SNAKE_CASE — is uppercase with underscores: USER_ACCOUNT_NAME.
Our Case Converter shows your text in all of these at once, plus Title Case, Sentence case, alternating and inverse, each with a copy button.
What each language expects
JavaScript and TypeScript use camelCase for variables and functions, PascalCase for classes and React components, and CONSTANT_CASE for module-level constants. Java and C# follow similar rules, though C# also uses PascalCase for public methods. Python's official style guide, PEP 8, mandates snake_case for variables and functions with PascalCase for classes. Ruby and Rust both use snake_case, with Rust adding PascalCase for types. Go uses camelCase and PascalCase, where capitalisation is not cosmetic at all — it controls whether an identifier is exported from the package.
The practical rule beats any personal preference: follow the convention of the language and codebase you are in. Mixed conventions inside one project cost more readability than any single convention could gain.
Where kebab-case belongs
kebab-case is rare inside code because a hyphen is a minus sign in nearly every language — user-name would parse as subtraction. It dominates everywhere outside the language, though: URLs and file slugs, CSS class names and custom properties, HTML attributes, npm package names, and command-line flags.
For URLs the choice matters for search: hyphens are treated as word separators, while underscores historically were not, so this-post-title is more legible to search engines than this_post_title. That is why blog slugs, including the ones on this site, use hyphens.
Why underscores versus humps at all
The split is historical. Early languages and systems were case-insensitive or uppercase-only, so underscores were the only way to separate words — that lineage runs through C to Python and Ruby. Case-sensitive languages that came later could use capitalisation instead, and camelCase spread through Smalltalk, then Java, then JavaScript.
Legibility research on the question is genuinely mixed: some studies find snake_case slightly faster to read accurately, others find camelCase faster to scan once you are trained on it. The effect sizes are small enough that consistency matters more than the choice.
Where conventions collide
Real projects cross boundaries constantly, and that is where the pain lives. A Python API returning snake_case JSON keys to a JavaScript frontend expecting camelCase is the classic case. Databases usually use snake_case for column names while the application layer uses whatever the language prefers. Environment variables are almost universally CONSTANT_CASE regardless of stack.
Two workable approaches: convert at the boundary, with a serialization layer that maps between conventions automatically, or agree to use the API's convention throughout the client and accept the inconsistency in exchange for never guessing. Pick one and document it — the failure mode is a codebase where both happen unpredictably.
Naming beyond the casing
Casing is the easy part. The harder rules: be consistent about abbreviations (either always URL or always Url, never both), avoid single letters outside tight loop counters, prefer descriptive length over cleverness since code is read far more than written, and keep boolean names phrased as questions — isActive, hasPermission, canEdit — so conditionals read as sentences.
One convention worth adopting deliberately: reserve CONSTANT_CASE strictly for genuine constants. When every reader knows that uppercase means this never changes, that signal does real work.
Acronyms: the argument that never ends
The messiest corner of naming is what to do with acronyms in camelCase. Is it parseXML or parseXml? getHTTPResponse or getHttpResponse? Both appear constantly, including inside the standard libraries of major languages, which is why nobody can win the argument by citing precedent.
The case for treating acronyms as ordinary words — parseXml, getHttpResponse — is that it keeps word boundaries visible, which matters enormously when two acronyms collide: parseXMLHTTPRequest is close to unreadable, while parseXmlHttpRequest is not. Google's style guides for several languages take this position. Whichever you choose, apply it mechanically across the codebase, because inconsistent acronym casing breaks every search-and-replace and every automated case conversion you will ever run.
Convert without retyping
Renaming a variable across conventions by hand invites typos. Paste it into our Case Converter and you get all eleven casings at once — it detects word boundaries from spaces, underscores, hyphens, and existing camelCase humps, so you can convert in any direction. It runs entirely in your browser, which matters when the strings you are converting come from private code.