camelCase, snake_case, kebab-case: A Naming Guide
Every codebase uses several naming conventions at once, and mixing them up is one of the fastest ways to make code look amateurish. The good news is that the choice is mostly not yours to make: your language decides, and within a language, the kind of thing being named decides the rest.
The five conventions
| Convention | Example | Primary use |
|---|---|---|
| camelCase | userFirstName | JS/Java variables, functions, properties |
| PascalCase | UserFirstName | Classes, types, React components |
| snake_case | user_first_name | Python, Ruby, SQL columns |
| kebab-case | user-first-name | URLs, CSS classes, CLI flags |
| CONSTANT_CASE | USER_FIRST_NAME | Constants, environment variables |
Rule one: the language decides the baseline
This is not a matter of taste, and it is not negotiable in a shared codebase. Python's PEP 8 specifies snake_case for functions and variables. JavaScript, Java, C#, Swift, and Kotlin all use camelCase for the same things. Ruby uses snake_case. Rust uses snake_case for values and PascalCase for types.
Writing getUserName in Python is not a style preference — it is a signal to every reviewer that you have not read the language's conventions. Match the ecosystem you are in, even if you personally prefer the other one.
Rule two: types get PascalCase, instances get camelCase
Nearly every language that uses camelCase also reserves PascalCase for types. This split does real work:
const userAccount = new UserAccount()
// ^ instance ^ typeYou can read that line and know what each name refers to without looking anything up. React makes the distinction load-bearing rather than merely conventional: JSX treats a lowercase tag as an HTML element and an uppercase one as a component, so <button> and <Button> are genuinely different things.
Rule three: constants shout
CONSTANT_CASE — also called SCREAMING_SNAKE_CASE — marks a value that never changes. It survives from an era before syntax highlighting, when capitals were the only way to show a reader that a value was fixed, and it stuck because it still works. An all-caps identifier in the middle of a function tells you the value comes from configuration rather than local state, without tracing where it was defined.
Environment variables are the one place this is truly universal: DATABASE_URL, STRIPE_SECRET_KEY, NODE_ENV. Every operating system, deployment platform, and CI system expects that shape.
Rule four: kebab-case is for things browsers read
Hyphens cannot appear in identifiers in most languages, because the parser reads them as subtraction. That single constraint decides the whole boundary: kebab-case lives outside your code, in URLs, CSS class names, HTML data attributes, command-line flags, npm package names, and file names.
For URLs specifically, hyphens are the better choice for search too. Google treats a hyphen as a word separator but does not reliably split on underscores, so /convert-case-online is understood as three words where /convert_case_online may be read as one.
Where the boundaries get crossed
The friction shows up at system boundaries. A Python or Ruby API returns user_first_name; the JavaScript client wants userFirstName. A Postgres table has snake_case columns; the ORM model has camelCase properties.
There is no universally correct answer, only a consistent one. Pick a single conversion point — usually the API client or the ORM layer — and convert everything there, so that each side of the boundary is internally consistent. What you must avoid is converting ad hoc in different places, which leaves you unable to predict which shape any given name has.
Renaming in bulk
When you do need to convert a batch of names, paste the whole list into the converter — one name per line — and click the target format. Existing capital boundaries, underscores, hyphens, and dots are all detected as word separators, so getUserID, get_user_id, and get-user-id all convert to the same result, and acronyms stay intact rather than exploding into single letters.