Every mainstream language and file format has its own convention for multi-word identifiers, and mixing them up is one of the most common friction points when moving between a frontend, a backend, a database, and a config file in the same project. Here's each style, and which contexts actually expect it.
The styles
- camelCase —
firstName. First word lowercase, each following word capitalized, no separators. - PascalCase —
FirstName. Same as camelCase, but the first word is also capitalized. - snake_case —
first_name. All lowercase, words separated by underscores. - CONSTANT_CASE (a.k.a. SCREAMING_SNAKE_CASE) —
FIRST_NAME. All uppercase, underscore-separated. - kebab-case —
first-name. All lowercase, hyphen-separated. - dot.case —
first.name. All lowercase, dot-separated — less common, mostly seen in config keys and some templating contexts.
What each language and context actually expects
- JavaScript / TypeScript — camelCase for variables and functions, PascalCase for classes/components/types.
- Python — snake_case for variables and functions (PEP 8), PascalCase for classes.
- Java / C# — camelCase for variables and methods, PascalCase for classes — the same split as JavaScript, but PascalCase reaches further in C# (properties and public methods are PascalCase too).
- Ruby — snake_case for methods and variables, PascalCase for classes/modules.
- Environment variables — CONSTANT_CASE is the near-universal convention across shells and languages (
DATABASE_URL,NODE_ENV). - CSS class names and URLs/slugs — kebab-case is standard (
main-nav,/user-settings) since underscores in a URL are harder to read and historically ambiguous with spaces in some contexts (e.g. an underlined link rendering_as indistinguishable from a space). - JSON — no enforced convention, but camelCase (matching JavaScript) and snake_case (matching Python/Ruby backends) are both extremely common depending on which ecosystem produced the API; a project consuming a third-party API takes whatever that API uses.
- Database columns (SQL) — snake_case is the dominant convention (
created_at,user_id), since SQL identifiers are traditionally case-insensitive unless quoted, which makes camelCase easy to accidentally break. - File names — varies by ecosystem: kebab-case is common for web assets and many CLI tools, PascalCase for component files in React/Vue projects, snake_case in Python and Ruby projects.
Why this matters more than it looks like it should
A single project frequently spans several of these conventions at once by design — a React frontend (camelCase props, PascalCase components) calling a Python API (snake_case JSON) backed by a Postgres database (snake_case columns), configured via CONSTANT_CASE environment variables. That's not inconsistency to "fix" — it's each layer correctly following its own ecosystem's norm. The actual failure mode is a translation step done inconsistently: a serializer that converts user_id to userId for some endpoints but not others, or a config value read with the wrong case in one environment. Converting between cases consistently, at a defined boundary, is what actually matters — not forcing one style everywhere.
Try it yourself
Paste text or a list of identifiers (one per line) into our Case Converter to see all styles at once — camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, Title Case, and more. Runs entirely in your browser.