Naming Conventions: How to Choose Between camelCase, snake_case, and kebab-case

No naming convention is inherently best — there's only "the convention of the ecosystem you're in": camelCase for JS/Java, snake_case for Python and databases, kebab-case for URLs and CSS, and PascalCase almost universally for type names. What really hurts productivity is mixing styles within one project. This site offers a case converter and a camelCase ↔ snake_case converter.

The four mainstream styles

Style	Example	Home turf
camelCase (lower camel)	userName	JS/Java/Go variables and functions, JSON fields
PascalCase (upper camel)	UserName	Class/component/type names in most languages
snake_case	user_name	Python/Ruby variables, database columns, env vars (uppercase USER_NAME)
kebab-case	user-name	URLs, CSS class names, CLI flags

Conversion strategy across systems

The most common pipeline: database snake_case → backend → JSON camelCase → frontend components. Recommendations:

• Convert centrally in the serialization layer (e.g. Jackson's SNAKE_CASE strategy in Java, pydantic alias in Python) instead of hand-writing a mapping for every field.
• Once you pick a direction, keep it consistent end to end: if your JSON is camelCase, every endpoint follows — no userName here and user_name there.
• Environment variables are always uppercase snake: DATABASE_URL.

Three things that matter more than style

1. Consistency > the style itself. A project that uses snake_case everywhere beats one that mixes two styles; when joining an existing project, follow what's already there — don't switch midstream.
2. Prefix booleans with is/has/can: isActive reveals its type at a glance; status does not.
3. Use plurals for collections: users is an array, user is a single object — this removes a lot of ambiguity from API docs.

Last updated: 2026-09-08