Case Converter

The Main Naming Conventions

Case conventions exist because most programming languages forbid spaces in identifiers, so multi-word names need some other way of showing where one word ends and the next begins. Over time each ecosystem settled on its own answer, and the differences are now strong enough that using the wrong one reads as a mistake even when the code compiles fine.

What Each Language Actually Expects

Following the local convention is not pedantry. Linters enforce it, code review flags it, and in at least one popular language it changes the meaning of your code.

• Python: PEP 8 specifies snake_case for functions, variables, and module names, PascalCase for classes, and SCREAMING_SNAKE_CASE for module level constants.
• JavaScript and TypeScript: camelCase for variables and functions, PascalCase for classes, React components, and type names. React in particular requires components to start with a capital letter, because JSX treats a lowercase tag as a plain HTML element.
• Go: PascalCase for exported identifiers and camelCase for unexported ones. Here capitalisation is semantically meaningful rather than stylistic: a leading capital is what makes a name visible outside its package, so renaming changes visibility.
• SQL: snake_case dominates because many databases fold unquoted identifiers to a single case (PostgreSQL lowercases them, Oracle uppercases them), so a CamelCase column silently becomes camelcase unless you quote it everywhere.
• CSS and URLs: kebab-case, partly because these contexts are case insensitive in places and partly because hyphens simply read better in long strings.

Why URLs Use kebab-case (and Why It Matters for SEO)

Search engines treat a hyphen as a word separator and an underscore as a word joiner. That single difference is the reason kebab-case is the standard for URL slugs.

There is a practical reason too: many web servers and file systems differ in how they treat letter case, so an all lowercase hyphenated path avoids duplicate URLs that resolve to the same page.

Acronyms: the Hard Part of Case Conversion

Splitting a name into words is easy when every word is lowercase with a single capital. It stops being easy the moment an acronym appears, because a run of consecutive capitals gives the parser no obvious boundary.

The usual heuristic is that a capital following another capital starts a new word only when the character after it is lowercase, which correctly turns HTTPResponse into HTTP plus Response. Style guides diverge on the output: Go recommends keeping acronyms fully capitalised (userID, ServeHTTP), while Java and much of the JavaScript world prefer treating them as ordinary words (userId, XmlParser). Pick one rule per codebase and let the linter enforce it, because inconsistent acronym casing is a persistent source of broken lookups when names are generated at runtime.