Few debates in programming feel more trivial and yet come up more often than the choice between snake_case and camelCase. In practice, the right choice usually comes down to one thing: your language's convention. But there are real nuances — especially in cross-language codebases and API design — worth understanding clearly.

At a Glance

snake_case
camelCase
user_name
userName
get_user_by_id
getUserById
total_page_count
totalPageCount
Words separated by underscores
Words joined, each starting with a capital (except first)

Language Conventions — the Definitive Guide

The single most important factor when choosing a naming convention is: what does the language ecosystem already use? Ignoring this creates friction every time a new developer joins the project or when you read library documentation.

Use snake_case

  • Python — PEP 8 explicitly mandates snake_case for variables, functions, and modules. Classes use PascalCase. Constants use SCREAMING_SNAKE_CASE.
  • Ruby — Same convention as Python by community standard.
  • Rust — Rust's compiler will warn you if you name a function with camelCase instead of snake_case.
  • SQL — Column and table names are traditionally snake_case: user_id, created_at, order_total.
  • Shell scripts / environment variables — Variables in bash are typically snake_case (lower) or SCREAMING_SNAKE_CASE for exports.

Use camelCase

  • JavaScript / TypeScript — Variables and functions use lowerCamelCase. Classes and types use PascalCase.
  • Java — The strongest tradition for camelCase. Even the standard library (System.out.println, ArrayList) follows it religiously.
  • C# / .NET — PascalCase for public members, lowerCamelCase for private fields and local variables.
  • Swift — Apple's Swift uses lowerCamelCase for variables and functions, PascalCase for types. It's enforced by style linters in most iOS projects.
  • Kotlin — Same as Java, camelCase throughout.
  • PHP — No single dominant style, but PSR-1/PSR-2 standards recommend camelCase for methods and PascalCase for classes.

Mixed: Go

Go is interesting — it uses camelCase everywhere, but visibility is determined by the first letter: exportedFunction is unexported (package-private), while ExportedFunction is exported (public). Underscores are avoided almost entirely.

Readability: Does It Actually Matter?

Several studies have looked at whether snake_case or camelCase is more readable. A widely cited 2010 study by Binkley et al. found that camelCase identifiers led to faster recognition in some tasks, but snake_case led to slightly higher accuracy. The differences were modest.

The more practical takeaway: consistency matters more than which convention you choose. A codebase that uniformly uses snake_case is more readable than one that mixes both randomly. Cognitive load comes from unexpected switches, not from the inherent style.

The API and Cross-Language Problem

One genuinely tricky situation is when your codebase crosses language boundaries. For example:

  • A Python backend that exposes a REST API consumed by a JavaScript frontend. Python code would naturally use user_name, but the JSON response should probably use userName for the JavaScript client.
  • A Java service storing records in a PostgreSQL database. Java uses userId, but the database column should probably be user_id.

The most common solutions:

  • Use a serialization layer that automatically converts between conventions (e.g., Django REST Framework's CamelCaseJSONParser, or JavaScript's humps library).
  • Standardize the API contract independently of internal conventions — and document it clearly.
  • Accept the mismatch in a bounded layer (the data access layer, the API controller) and keep the rest of the codebase consistent.
Practical rule: Follow your language's convention within a single codebase. At language boundaries (JSON, databases, inter-service calls), agree on a contract and use automatic conversion tools rather than hand-coding transformations.

What About kebab-case?

There's a third common convention you'll encounter: kebab-case (also called slug-case), where words are separated by hyphens: my-component, user-profile. This is standard for:

  • CSS class names and HTML attributes
  • URL paths and slugs
  • File names in many projects (especially frontend)
  • CLI flags (--output-file)

Kebab-case is generally not used inside source code because the hyphen is a subtraction operator in most languages.

Quick Conversion with Text Tools

Need to convert a list of identifiers between conventions? Paste your text into our free text converter and click snake_case or camelCase to transform it instantly. The converter handles spaces, hyphens, existing underscores, and mixed casing.

Related Articles