Case Naming Conventions: camelCase, snake_case, kebab-case

Case Styles at a Glance

Developers spend a surprising amount of time renaming things between case styles. An API returns user_id. Your JavaScript frontend wants userId. A CSS class is nav-bar. A Python function is calculate_total. Knowing which style belongs where avoids friction with libraries, frameworks, and teammates.

The four common styles:

| Style | Example | Separator | |---|---|---| | camelCase | firstName | Capital letter | | PascalCase | FirstName | Capital letter | | snake_case | first_name | Underscore | | kebab-case | first-name | Hyphen |

Each style has its home languages and its incompatible languages. Using the wrong one in a codebase signals that you haven't read the conventions. It makes your code harder to read for everyone who has.

camelCase

Words are joined without separators. The first word is lowercase. Every subsequent word starts with a capital letter.

Where it's used:

• JavaScript/TypeScript: variable names, function names, object keys (convention, not enforced by the language)
• Java: method names and variable names
• Go: exported identifiers (json:"userName" in struct tags)

camelCase is the dominant convention in the JavaScript ecosystem. If you're writing React, Node.js, or any browser code, camelCase is the safe default.

Here is what happens when you break the convention. A Python developer who doesn't know JavaScript writes fetch_user_data() in a Node.js codebase. It works. The interpreter doesn't care. But every JavaScript developer who reads the code pauses, wonders if it's intentional, and loses trust in the codebase. Conventions aren't about the machine. They're about the humans.

PascalCase

Like camelCase, but the first word also starts with a capital letter.

Where it's used:

• JavaScript/TypeScript: class names, React component names, TypeScript interfaces and types
• C#: class names, method names, properties
• Java: class names

The rule in TypeScript: if it produces a value at runtime, use camelCase (functions, variables). If it's a type or a component, use PascalCase. This distinction gives you an instant signal about what you're looking at. When you see <UserProfile />, you know it's a component. When you see userProfile, you know it's an instance or a variable.

snake_case

Words are joined by underscores. All lowercase (sometimes all uppercase for constants).

Where it's used:

• Python: variable names, function names, method names (PEP 8)
• Ruby: method names and variable names
• SQL: table and column names (convention, varies by shop)
• C: function names and variable names (convention)
• Rust: variable names and function names

Python's PEP 8 explicitly mandates snake_case for functions, methods, and variables. If your Python codebase uses camelCase, it's going against the grain of the entire ecosystem. Linters like pylint and flake8 will flag every instance. Autocomplete suggestions from libraries will use snake_case. Your code will look foreign.

A common pitfall: developers coming from Python to JavaScript (or vice versa) mix styles unconsciously. A Python developer writes processIncomingData in a Django view. A JavaScript developer writes process_incoming_data in an Express route. Both are valid syntax in both languages. Both are wrong for the ecosystem they're in.

kebab-case

Words are joined by hyphens. Always lowercase.

Where it's used:

• CSS: class names, IDs, custom properties
• HTML: data- attributes
• URLs: path segments (by convention, not enforced)
• Lisp: symbols

kebab-case is the standard for CSS because hyphens are valid in CSS identifiers and are conventionally used for multi-word properties (background-color, font-size). If you use underscores or camelCase in CSS class names, you're fighting the convention that every CSS framework and methodology (BEM, SMACSS, Tailwind utility classes) follows.

A practical concern: hyphenated CSS classes are easier to read at a glance than camelCase ones. Compare .nav-bar-dropdown-item to .navBarDropdownItem. In a stylesheet with hundreds of classes, the hyphens act as visual separators that reduce reading fatigue.

SCREAMING_SNAKE_CASE

All uppercase with underscores. Used for constants and environment variables:

const MAX_RETRY_COUNT = 3;
const API_BASE_URL = "https://api.example.com";

DATABASE_URL = "postgresql://localhost/mydb"
MAX_CONNECTIONS = 50

In C, preprocessor macros use it (#define BUFFER_SIZE 1024). In Go, it's uncommon (Go uses PascalCase for exported constants). In shell scripts, environment variables are conventionally UPPER_CASE with underscores.

When Styles Collide: Cross-Language Work

The most common case conflict happens when a JSON API (snake_case in many backends) meets a JavaScript frontend (camelCase). Your Express server sends { "user_id": 42, "first_name": "Alice" } and your React component expects { userId: 42, firstName: "Alice" }.

Three ways to handle this:

1. Transform on the client: write a mapper that converts snake_case keys to camelCase after receiving the response.
2. Transform on the server: the API serializes with camelCase keys. Some ORMs and serializers (like Django REST Framework's camelize) do this automatically.
3. Pick one and stick with it: some teams standardize on snake_case everywhere, including in the frontend. It works but feels foreign to JavaScript developers.

Converting Between Styles

Renaming manually is tedious and error-prone. Variables like customer_billing_address_line_2 have four words to track. A Case Converter handles this in one click:

1. Paste customer_billing_address_line_2.
2. Select camelCase output.
3. Copy customerBillingAddressLine2.

The same tool handles PascalCase, kebab-case, and SCREAMING_SNAKE_CASE. For batch conversions, some editors (VS Code with the "Change Case" extension) let you transform selections with keyboard shortcuts. But for one-off conversions where you don't want to install anything, the browser tool is faster.

Try it yourself: open the Case Converter. Paste hello_world and cycle through the output modes: camelCase, PascalCase, kebab-case, and snake_case. Each output transforms cleanly. Try a longer string like convert_this_string_please to see how the tool handles multi-word inputs.

Related Reading

• How to Generate SEO-Friendly URL Slugs
• Common JSON Syntax Errors and How to Fix Them
• How to Compare Two Text Files Line by Line