Naming Conventions
Across Languages

Why Naming Conventions Exist

Programming languages don't allow spaces in identifiers — my variable name is a syntax error everywhere. So every language community settled on a convention for writing multi-word identifiers. JavaScript uses camelCase. Python uses snake_case. CSS uses kebab-case. These aren't arbitrary — each convention evolved alongside the language's own syntax constraints. JavaScript adopted camelCase from Java, its syntactic inspiration. Python adopted snake_case from the C community and formalized it in PEP 8. CSS adopted kebab-case because hyphens are valid in CSS identifiers but minus signs aren't — the parser can distinguish background-color (one identifier) from background - color (subtraction).

Using the wrong convention in a codebase signals to every other developer that you didn't read the style guide. In Python, fetchUserData stands out as foreign. In JavaScript, fetch_user_data does the same. The convention itself matters less than consistency — a codebase that uses one convention uniformly is readable; a codebase that mixes them is exhausting.

The Five Case Formats

camelCase              — JavaScript, Java, TypeScript, Go (unexported identifiers)
snake_case             — Python, Ruby, Rust, PHP, C, PostgreSQL
kebab-case             — CSS, HTML attributes, URLs, CLI arguments, file names
PascalCase             — C#, .NET, React components, Java classes, TypeScript types
UPPER_CASE             — Constants, environment variables, enum values across most languages

Language-by-Language Reference

Language	Variables	Functions	Classes	Constants
JavaScript	camelCase	camelCase	PascalCase	UPPER_CASE
Python	snake_case	snake_case	PascalCase	UPPER_CASE
Go	camelCase*	camelCase*	PascalCase*	PascalCase
Rust	snake_case	snake_case	PascalCase	UPPER_CASE
Ruby	snake_case	snake_case	PascalCase	UPPER_CASE
C#	camelCase	PascalCase	PascalCase	PascalCase
PHP	$camelCase	snake_case	PascalCase	UPPER_CASE
CSS	kebab-case	—	—	—

* Go uses case for visibility: lowercase = unexported (private), uppercase = exported (public). This means Go uses BOTH camelCase and PascalCase, determined by visibility rather than the kind of identifier.

When to Convert Between Cases

API integration. The classic full-stack friction point. Your Python backend returns {"user_id": 1, "first_name": "Jane", "created_at": "2024-01-01"}. Your JavaScript frontend wants {"userId": 1, "firstName": "Jane", "createdAt": "2024-01-01"}. Every key in every API response needs conversion. Most teams handle this in one of two ways: a recursive key-transform utility on the frontend (after JSON.parse, before the data enters the app), or a serializer configuration on the backend that outputs camelCase JSON. Either works. Doing neither leads to a codebase where half the keys are snake_case and half are camelCase — a permanent source of bugs and confusion for new team members.

Database to application code. SQL column names are snake_case by convention. PostgreSQL automatically lowercases unquoted identifiers. When these columns become object properties in Node.js or Python, they stay snake_case. Many teams keep database column names as-is in application code rather than mapping them — the mapping layer adds complexity without much benefit. But if you're building an ORM or API that exposes column names to external consumers, convert to the language's convention at the boundary.

CSS in React. CSS properties use kebab-case: background-color, border-radius, font-size. React's inline style API maps these to camelCase: backgroundColor, borderRadius, fontSize. React handles the conversion. If you write background-color in a React inline style, it won't work — the framework expects camelCase.

File naming. Use kebab-case for files and folders across all projects: user-profile.tsx, api-client.js, password-reset-handler.go. It's safe on all operating systems (no case-sensitivity issues between Mac, Windows, and Linux), it's readable without requiring the Shift key, and it's the convention adopted by virtually all modern web frameworks. Google specifically recommends hyphens over underscores in URLs for SEO — underscores are treated as word joiners, hyphens as word separators.

Use our Text Case converter to switch between all five formats. Paste text in any case, convert to any other. It handles the edge cases — consecutive uppercase letters, numbers embedded in words, and special characters — that naive regex replacement gets wrong.

Edge Cases That Break Naive Conversion

XMLParser → snake_case: Should this be xml_parser or x_m_l_parser? A good converter recognizes "XML" as a single acronym when preceded by another uppercase letter. iPhone12 → PascalCase: Should be IPhone12 or Iphone12? There's no single right answer — it depends on whether you treat the leading lowercase 'i' as part of the word "iPhone" or as a prefix. userID → snake_case: Should be user_id or user_i_d? "ID" is generally treated as a single word. These edge cases are why hand-rolled case conversion functions tend to accumulate bugs over time — you fix one case and break another. A dedicated tool handles the most common patterns and lets you manually adjust the edge cases.

Case Conversion in Full-Stack Projects

When your Python backend sends snake_case JSON to your JavaScript frontend expecting camelCase, every key needs conversion. Most teams handle this with a transformation layer rather than manual conversion. On the backend, Django REST Framework has a camelCase renderer; FastAPI can configure response serialization. On the frontend, libraries like camelcase-keys and humps recursively transform object keys. The transformation should happen at exactly one boundary — either the backend serializes in the clients format, or the frontend normalizes after receiving. Doing both creates double-conversion bugs where snake_case becomes camelCase becomes something unrecognizable.

For database integrations, most ORMs handle naming convention mapping. SQLAlchemy can auto-map snake_case PostgreSQL columns to camelCase Python properties. Sequelize and TypeORM offer underscored options for Node.js. If your ORM lacks this, write a single utility function rather than sprinkling ad-hoc conversions through your codebase. A function named snakeToCamel(str) called in one place is maintainable and testable. Fifty inline regex replacements are neither.

Enforcing Naming Conventions in a Team

The best naming convention is the one your team actually follows. A documented convention that nobody enforces is worse than no convention at all — it creates inconsistency, which is more confusing than consistently "wrong" naming. Enforce conventions with automated tooling: ESLint rules for JavaScript (camelcase, @typescript-eslint/naming-convention), Pylint or Black for Python (snake_case is the default), Stylelint for CSS (kebab-case), and Prettier for general formatting. If your linter catches naming violations before code review, developers fix them immediately rather than debating them in PR comments.

When onboarding new team members, point them to your naming convention documentation and your linter config. Do not rely on them "picking up" the conventions by reading existing code — different parts of a legacy codebase may follow different conventions, and a new developer cannot distinguish "this is our convention" from "this file was written before we adopted conventions." Explicit documentation plus automated enforcement removes the ambiguity.