camelCase vs snake_case: when to use which (with real examples)

Ask two developers about naming conventions and you will get three opinions. But underneath the debates, there are practical rules that most communities follow. Ignore them and your code works fine — until you hand it to someone else, or integrate with an external API, or run a linter that flags every variable in the codebase. Here is a reference guide covering the five main case formats, which languages and contexts use each one, and how to convert between them without writing a script.

camelCase

Words joined together, first word lowercase, subsequent words capitalised: getUserData, isLoading, maxRetryCount, handleSubmitClick.

Use when: JavaScript and TypeScript variables and functions; Java variables and methods; JSON keys in most REST APIs; React props and state variables; Swift properties and methods.

Avoid when: Python (PEP 8 explicitly prefers snake_case for variables and functions); CSS class names (use kebab-case); URL paths; database column names.

Edge case: Abbreviations in camelCase are a style debate. Some teams write httpRequest, others insist on HTTPRequest for readability. Pick one convention and apply it consistently. Most modern style guides (Google, Airbnb) prefer treating abbreviations as words: httpRequest, xmlParser, urlEncoder.

PascalCase

Same as camelCase but the first word is also capitalised: UserProfile, HttpRequest, DataProcessor, OrderLineItem.

Use when: Class names in almost every object-oriented language — Python, Java, JavaScript, TypeScript, C#, PHP, Ruby; React component names (this is enforced by JSX — lowercase components are treated as HTML elements); TypeScript interfaces, types, and enums; C# methods (unlike Java, C# capitalises methods); constructor functions in JavaScript.

Why it exists as a separate category from camelCase: The capitalised first letter is a visual signal that this identifier creates something (a class, a component, a type) rather than holding or transforming something (a variable or function). In a codebase where you see both userProfile and UserProfile, the first is an instance and the second is the blueprint.

snake_case

Words separated by underscores, all lowercase: user_profile, max_retry_count, is_loading, process_payment_request.

Use when: Python variables, functions, and module names (PEP 8 is explicit); database column names (SQL convention across most databases); Ruby variables and methods; PHP variables in many frameworks; file names in Unix/Linux systems where spaces in filenames cause problems; configuration keys in many config file formats.

Why it is easier to read for humans: Studies on identifier readability consistently show that snake_case performs better than camelCase for recognition speed, especially for non-native English speakers and for identifiers with three or more words. The underscore creates a clear visual separation that the eye parses without effort. Whether this justifies using it in a JavaScript codebase where camelCase is the convention is a different question — consistency with the ecosystem beats marginal readability gains.

kebab-case

Words separated by hyphens, all lowercase: user-profile, max-retry-count, is-loading, primary-action-button.

Use when: CSS class names and custom properties (--color-primary); HTML attributes (data-user-id); URL slugs and paths (/blog/how-to-clean-text); CLI flags and options (--dry-run, --output-format); config file keys in YAML and TOML when snake_case is not specified.

Critical note: You cannot use kebab-case as a JavaScript variable or function name. The hyphen is the subtraction operator. let user-profile = ... is a syntax error. This is why CSS-in-JS frameworks like styled-components use camelCase in their JavaScript API (backgroundColor) but output kebab-case in the actual CSS (background-color). When bridging between JavaScript and CSS, you are always translating between these two conventions.

CONSTANT_CASE (SCREAMING_SNAKE_CASE)

All uppercase, words separated by underscores: MAX_RETRIES, API_BASE_URL, DEFAULT_TIMEOUT_MS, NODE_ENV.

Use when: Environment variables — universally, in every language and platform; compile-time constants in C and C++; Java constants (by strong convention, even though the language does not enforce it); Python module-level constants (PEP 8 explicitly recommends this); configuration values that are set once and should never be mutated at runtime.

The signal it sends: CONSTANT_CASE is visual documentation. When you see an all-caps identifier in code, you know immediately that this value is set externally or defined once and is not supposed to change. This convention is so consistent across languages and teams that violating it — using CONSTANT_CASE for a variable that actually mutates — creates genuine confusion in code review.

Converting between formats in practice

The most common conversion scenario is moving between Python and JavaScript: a Python API uses snake_case for its JSON responses, but the JavaScript frontend consuming that API expects camelCase. You have three options: transform in the API layer, transform in the JavaScript fetch/parse layer, or transform manually when setting up the integration.

For the manual case — say you have a block of 60 Python variable names you need to convert to camelCase for a React component — the Convert Case tool handles this in bulk. Paste the snake_case names one per line, pick camelCase from the dropdown, copy the result. The tool handles edge cases like consecutive underscores and preserves leading underscores (used for private variables in Python) correctly.

For the other direction — camelCase JavaScript API response keys you need to map to snake_case database columns — the same tool works in reverse. Paste the camelCase keys, select snake_case, done.

When conventions conflict

The conflict that comes up most often: you are writing a JavaScript file that imports from a Python-style config and exposes a REST API that a Ruby client will consume. Python wants snake_case, JavaScript wants camelCase, the REST API conventionally uses kebab-case for URL paths and camelCase for JSON body keys, and Ruby will follow whatever the API sends. The answer is to pick the right convention at each boundary and transform at the boundaries — use camelCase inside your JavaScript, kebab-case in your URL paths, and a consistent serialisation layer that handles the snake_case ↔ camelCase mapping when reading from config or writing to the API response.