Naming conventions look like a matter of taste and mostly are not. Your language decides the baseline, and within a language the kind of thing being named decides the rest. Getting it wrong is one of the fastest ways to make code look amateurish.

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, file names
CONSTANT_CASE	`USER_FIRST_NAME`	Constants, environment variables

Rule one: the language sets the baseline

This is not negotiable in a shared codebase. Python's PEP 8 specifies snake_case for functions and variables. JavaScript, Java, C#, Swift, and Kotlin use camelCase. Ruby uses snake_case. Rust uses snake_case for values and PascalCase for types.

Writing getUserName in Python signals to every reviewer that you have not read the conventions. Match the ecosystem you are in, even if you prefer the other.

Rule two: types get PascalCase, instances get camelCase

Nearly every language using camelCase also reserves PascalCase for types, and the split does real work:

const userAccount = new UserAccount()
//    ^ instance         ^ type

React makes this load-bearing rather than conventional: JSX treats a lowercase tag as an HTML element and an uppercase one as a component, so <button> and <Button> are genuinely different.

Rule three: constants shout

CONSTANT_CASE marks a value that never changes. It predates syntax highlighting, when capitals were the only cue that a value was fixed, and it survived because it still works — an all-caps identifier tells you the value comes from configuration without tracing where it was defined.

Environment variables are the universal case: DATABASE_URL, NODE_ENV, STRIPE_SECRET_KEY.

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 sets the boundary: kebab-case lives outside your code, in URLs, CSS class names, HTML data attributes, CLI flags, npm package names, and file names.

For URLs it is also better for search — Google treats hyphens as word separators but does not reliably split on underscores. See How to Write URL Slugs That Rank.

Beyond code: naming anything consistently

The same thinking applies outside programming:

File names — lowercase, hyphens, no spaces. Prefix with zero-padded numbers (01-intro) so they sort correctly.
Spreadsheet columns — pick one case and never mix. "Customer Name" and "customer_name" in the same workbook will cost you an hour eventually.
Database columns — snake_case, because Postgres folds unquoted identifiers to lowercase anyway.
URLs — kebab-case, always lowercase.

Crossing boundaries

Friction appears where systems meet. A Python 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 ORM layer — and convert everything there, so each side of the boundary is internally consistent. What you must avoid is converting ad hoc in different places, leaving you unable to predict which shape any name has.

Converting in bulk

All the converters detect word boundaries from spaces, underscores, hyphens, dots, and existing capitals, so getUserID, get_user_id, and get-user-id all convert to the same result. Acronyms stay intact rather than exploding into single letters — parseHTTPResponse becomes parse_http_response.

Paste one name per line to convert a whole column of database fields or form names at once; line breaks are preserved.

The underlying principle

Naming conventions are not about correctness — every style is readable once you are used to it. They are about predictability. When names follow a rule, you can guess the name of something you have not seen yet, and that guess is right often enough to save real time.

That is why consistency beats any individual choice, and why the worst codebase is not the one using the wrong convention but the one using three.

For the deeper reasoning behind each language's choices, see camelCase, snake_case, kebab-case: A Naming Guide.

The Complete Guide to Naming Conventions