Case Converter

Which case goes where

Every language and config format has its own convention. Picking the wrong one is the kind of thing a linter complains about all day, so here is the cheat sheet:

Converting in your own code

When you need this in a build step rather than by hand, the trick is always to split the input into words first, then re-join them in the target style.

// snake_case → camelCase (JavaScript)
"user_first_name".replace(/_([a-z])/g, (_, c) => c.toUpperCase());
// → "userFirstName"

# camelCase → snake_case (Python)
import re
re.sub(r'(?<!^)(?=[A-Z])', '_', "userFirstName").lower()
# → "user_first_name"

One source phrase, every style: user first name becomes userFirstName, UserFirstName, user_first_name, user-first-name and USER_FIRST_NAME.

The seam where two conventions meet

Naming styles rarely cause trouble inside one file. The pain shows up at the boundaries, where code in one convention talks to data in another. A JavaScript front end usually wants camelCase, but plenty of JSON APIs ship snake_case field names because the backend is Python or Ruby, or because the database columns are snake_case and nobody mapped them. So you either convert on the wire, convert in the client, or live with user.first_name sitting awkwardly in otherwise-camelCase JavaScript. None of those is wrong; the mistake is doing it inconsistently, so half your codebase says firstName and the other half first_name and every developer has to remember which is which for every endpoint.

Databases add their own layer. SQL is traditionally snake_case, and most ORMs quietly map a created_at column to a createdAt or CreatedAt property to keep each side idiomatic. Constants and environment variables go the other way into CONSTANT_CASE (DATABASE_URL, MAX_RETRIES), a convention so universal that a lowercase env var looks like a typo. And anything that ends up in a URL or a filename wants kebab-case, partly for readability and partly because URLs are case-sensitive on a Linux server even when they aren't on your Mac, so My-Page and my-page can resolve to different things once you deploy.

Acronyms and numbers, where converters disagree

Splitting a name into words is easy until an acronym shows up. Should parseHTTPResponse become parse_http_response or parse_h_t_t_p_response? Languages genuinely disagree: Go's style guide keeps initialisms uppercase as a unit (ServeHTTP), while C#'s leans toward treating them as ordinary words (ParseHttpResponse). No converter can read your intent, so a tool will pick one rule and apply it everywhere, which is exactly why you should glance over any identifier with an acronym before committing it. Numbers are the smaller cousin of the same problem: is address2 one token or two, and does utf8 split before the 8? Pick a convention, write it down, and let consistency do the work that cleverness can't.