Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions (With Free Tools)

Muhammad Ali — Wed, 19 Aug 2026 20:02:39 +0000

Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions

If you've ever migrated a PostgreSQL schema to a JSON API, you know the pain.

Database columns are user_profile_id. Your React components expect userProfileId. Your URL slugs need user-profile-id. And someone on the team just committed UserProfileID because they were in a hurry.

Naming conventions are not glamorous. But inconsistent casing causes real bugs — failed API calls, broken ORM mappings, and lint errors that block your PR at 4:55 PM on a Friday.

This post is a practical guide to the six conventions you'll encounter in the wild, when to use each one, and how to convert between them without manual find-and-replace.

Full reference guide: I published a deeper walkthrough with examples for every layer of the stack at CaseSwitch.

The six conventions you'll actually use

1. camelCase — `userProfileId`

Where: JavaScript/TypeScript variables, JSON API keys, Java methods.

const userProfileId = response.data.userProfileId;
function fetchOrderHistory() { /* ... */ }

Rule: First word lowercase, each following word capitalized. No separators.

2. PascalCase — `UserProfileCard`

Where: React components, TypeScript interfaces, C# classes.

interface OrderSummary { total: number; }
export function UserProfileCard() { /* ... */ }

Rule: Same as camelCase, but the first letter is also capitalized.

3. snake_case — `user_profile_id`

Where: Python (PEP 8), Ruby, SQL columns, environment variables in some stacks.

def fetch_user_profile(user_id: int) -> dict:
    return db.query(user_id)

SELECT user_profile_id FROM order_history;

4. kebab-case — `user-profile-id`

Where: URL slugs, CSS classes, HTML data-* attributes, CLI flags.

https://myapp.com/user-profile/settings

.nav-bar-item { display: flex; }

SEO note: Google treats hyphens as word separators in URLs. Underscores are not treated the same way.

5. dot.case — `user.profile.id`

Where: i18n translation keys, nested config paths, Lodash-style accessors.

{
  "errors.validation.email.invalid": "Please enter a valid email."
}

6. SCREAMING_SNAKE_CASE — `MAX_RETRY_COUNT`

Where: Constants, environment variables, some legacy codebases.

const MAX_RETRY_COUNT = 3;
// .env: DATABASE_URL=postgres://...

How conventions map across a typical stack

Here's what a full-stack project often looks like:

Layer	Convention	Example
Database	snake_case	`user_profile_id`
API JSON	camelCase	`userProfileId`
React component	PascalCase	`UserProfileCard`
URL route	kebab-case	`/user-profile`
CSS class	kebab-case	`.profile-card`
i18n key	dot.case	`errors.email.invalid`
Env var	SCREAMING_SNAKE	`DATABASE_URL`

The ORM or serializer handles DB → API transformation. But when you're writing migrations, docs, or one-off scripts, you're doing the conversion yourself.

The migration patterns that break teams

Database → API. You export a CSV with first_name, last_name, email_address and need camelCase keys for a seed script.

Spreadsheet → code. Product sends a column list in Title Case. Engineering needs snake_case for migrations.

Blog title → URL slug. "How to Write SEO-Friendly URLs" becomes how-to-write-seo-friendly-urls.

Legacy codebase cleanup. Half the variables are camelCase, half are snake_case, and ESLint is screaming.

Manual conversion fails at scale. Automated converters handle word boundaries consistently.

Free tools I use for this

I built CaseSwitch — a collection of 100+ browser-based utilities. The case converters are what I reach for most:

camelCase Converter — user profile id → userProfileId
snake_case Converter — userProfileId → user_profile_id
kebab-case Converter — user profile id → user-profile-id
PascalCase Converter — user profile card → UserProfileCard
Slug Generator — blog titles → URL-safe slugs

Everything runs locally in the browser. I use these when formatting API keys and migration drafts — nothing gets uploaded.

Common mistakes (and how to avoid them)

Mixing conventions in the same API response. Pick one style per layer and enforce it with linters.

Using kebab-case in JavaScript variable names. Hyphens are minus operators. Use camelCase.

Title Case in database columns. Requires quoting in SQL and breaks most ORMs.

Ignoring acronyms. Decide upfront: apiKey or APIKey? Document it in your style guide and stick to it.

Converting without checking output. Automated tools don't know that iPhone and JavaScript have special casing. Always scan results before committing.

What's your biggest naming convention headache?

Drop a comment — I'm curious whether it's database migrations, API design, or CSS class naming that causes the most friction on your team.

If this was useful, the full guide on CaseSwitch goes deeper on each convention with a quick-reference conversion table.

CaseSwitch is free, requires no account, and processes most tools locally in your browser. Try it →

DEV Community: Muhammad Ali

Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions (With Free Tools)

Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions

The six conventions you'll actually use

1. camelCase — `userProfileId`

2. PascalCase — `UserProfileCard`

3. snake_case — `user_profile_id`

4. kebab-case — `user-profile-id`

5. dot.case — `user.profile.id`

6. SCREAMING_SNAKE_CASE — `MAX_RETRY_COUNT`

How conventions map across a typical stack

The migration patterns that break teams

Free tools I use for this

Common mistakes (and how to avoid them)

Further reading

What's your biggest naming convention headache?

DEV Community: Muhammad Ali

Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions (With Free Tools)

Stop Hand-Renaming Variables: A Developer's Guide to Case Conventions

The six conventions you'll actually use

1. camelCase — userProfileId

2. PascalCase — UserProfileCard

3. snake_case — user_profile_id

4. kebab-case — user-profile-id

5. dot.case — user.profile.id

6. SCREAMING_SNAKE_CASE — MAX_RETRY_COUNT

How conventions map across a typical stack

The migration patterns that break teams

Free tools I use for this

Common mistakes (and how to avoid them)

Further reading

What's your biggest naming convention headache?

1. camelCase — `userProfileId`

2. PascalCase — `UserProfileCard`

3. snake_case — `user_profile_id`

4. kebab-case — `user-profile-id`

5. dot.case — `user.profile.id`

6. SCREAMING_SNAKE_CASE — `MAX_RETRY_COUNT`