DEV Community

Muhammad Ali
Muhammad Ali

Posted on Originally published at caseswitch.net

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

#webdev #programming #productivity #javascript

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() { /* ... */ }
Enter fullscreen mode Exit fullscreen mode

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() { /* ... */ }
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode 
SELECT user_profile_id FROM order_history;
Enter fullscreen mode Exit fullscreen mode

4. kebab-case — user-profile-id

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

https://myapp.com/user-profile/settings
Enter fullscreen mode Exit fullscreen mode 
.nav-bar-item { display: flex; }
Enter fullscreen mode Exit fullscreen mode

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."
}
Enter fullscreen mode Exit fullscreen mode

6. SCREAMING_SNAKE_CASE — MAX_RETRY_COUNT

Where: Constants, environment variables, some legacy codebases.

const MAX_RETRY_COUNT = 3;
// .env: DATABASE_URL=postgres://...
Enter fullscreen mode Exit fullscreen mode

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:

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.

Further reading

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 →

Top comments (0)