Case Converter

The cases and where each belongs

camelCase starts lowercase and capitalises each subsequent word; it is the convention for variables and functions in JavaScript, Java and Swift. PascalCase capitalises the first word too and is generally reserved for types, classes and components. snake_case joins lowercase words with underscores and is standard in Python, Ruby, Rust and SQL identifiers. SCREAMING_SNAKE_CASE is the same with capitals, used almost exclusively for constants and environment variables.

kebab-case joins lowercase words with hyphens and belongs to places where underscores are awkward or invisible: URL slugs, CSS class names and custom properties, HTML attributes, command-line flags, npm package names. dot.case appears in configuration keys and namespaced settings.

Picking the right one is rarely a matter of taste. Each ecosystem has a convention, linters enforce it, and an identifier in the wrong case reads as foreign in the file it lands in.

Word splitting is the hard part

Converting between cases is easy once you know where the words are, and finding the words is where naive implementations fall over. The input is split on underscores, hyphens, dots and spaces, and also on case boundaries, so parsing userName and user_name gives the same two words.

Runs of capitals are treated as one word rather than one word per letter. XMLHttpRequest splits as XML, Http, Request, giving xml_http_request rather than x_m_l_http_request, and getUserID keeps ID whole. The rule is that a run of capitals ends one character before a following lowercase letter, which is what makes the H in Http start a new word rather than finish the previous one.

Digits attach to the word they follow, so parseInt32 splits as parse, Int32. Leading and trailing separators are dropped, and repeated ones collapse.

Prose cases, and CJK

Title Case is not simply capitalising every word. English style guides keep articles, short prepositions and coordinating conjunctions lowercase unless they open or close the title, which is why the result is The Lord of the Rings rather than The Lord Of The Rings. The guides disagree about where the line falls, particularly on prepositions of four or more letters, so check yours if it matters. Sentence case capitalises only the first word and leaves the rest, which is increasingly the house style for headings.

Japanese, Chinese and Korean have no case distinction at all, so those characters pass through untouched. In mixed text only the Latin runs are converted. A CJK run is treated as a single word because splitting it into words requires a dictionary and a segmenter, and guessing at boundaries would produce confidently wrong output.

Round-tripping is lossy

Converting an identifier to another case and back does not always return what you started with. snake_case to camelCase and back is safe, because the underscore boundaries survive as case boundaries. Anything involving an acronym is not: HTTPServer becomes http_server, and converting that back gives HttpServer. The information that HTTP was an acronym existed only in the capitalisation, and lowercasing discarded it.

This matters when renaming across a codebase, and it is the reason to convert once from the original rather than chaining conversions.

Why the conventions differ at all

None of these styles is better than the others; they are accidents of history that hardened into community standards. C and its descendants in Unix favoured lowercase with underscores because early linkers were case-insensitive and long names were expensive. Smalltalk popularised camelCase, Java inherited it, and JavaScript followed Java closely enough to inherit it again.

Python's style guide codified snake_case for functions and variables and PascalCase for classes, and the strength of that document is why Python code looks consistent across projects in a way that older languages never managed. CSS and HTML settled on kebab-case partly because their grammars are case-insensitive and partly because hyphens read naturally in a language without identifiers.

The practical consequence is that the right case is whatever the surrounding ecosystem uses. A Python file full of camelCase is harder to read not because the style is worse but because it breaks the pattern every other file in the project follows.

Crossing a boundary between two conventions

Most real systems have at least one seam where the conventions change. A PostgreSQL schema uses snake_case because unquoted identifiers are folded to lowercase; the JSON API in front of it usually uses camelCase; the React component consuming that JSON uses PascalCase for the component and camelCase for its props; and the CSS class it renders is kebab-case.

Converting at the seam, in one place, is what keeps this manageable. ORMs and serialisation libraries almost all offer a naming strategy setting for exactly this, and using it beats hand-mapping every field, which is where typos and silently-missing properties come from.

The one thing to avoid is converting twice, or converting in both directions at different layers. When a field arrives as user_name, becomes userName in the client, and is sent back as userName to an API that expected user_name, the mismatch usually surfaces as a value quietly ignored rather than an error.

Renaming across a codebase without breaking it

A rename is a search-and-replace only in the simplest cases. The same identifier may appear as a variable, in a string used for serialisation, in a database column, in a URL path, and in documentation, and those are not all the same change - renaming the variable is safe, renaming the serialised key is a breaking API change.

The order that works is to convert once from the original name rather than chaining conversions, because acronyms do not survive a round trip: HTTPServer becomes http_server and comes back as HttpServer. Generate the whole mapping first, review it, then apply it.

Linters are the durable fix. ESLint, Ruff, golint and their equivalents can enforce a naming convention on new code, which stops the problem recurring after the one big rename is done.

Case is not simple in every language

Uppercasing and lowercasing are locale-dependent operations, and a few well-known cases break naive code. In Turkish, the uppercase of i is dotted, and lowercasing I gives a dotless character - which is why a case-insensitive comparison done in a Turkish locale can fail to match identifiers that look identical in English. The usual defence is to lowercase with an invariant locale when the text is an identifier rather than prose.

German ß uppercases to SS, so the operation changes the length of the string, and round-tripping does not return the original. Greek sigma has two lowercase forms depending on whether it ends a word. None of this affects ASCII identifiers, which is most code, but all of it affects user-supplied text.

The conversions here operate on Latin text and leave Japanese, Chinese and Korean characters untouched, since those writing systems have no case distinction at all.

Naming is the part that outlives the code

Case conversion is mechanical; choosing the words is not, and the words are what a reader actually struggles with. A consistent style makes a codebase readable at a glance, but a consistently applied bad name is still a bad name, and renaming is cheap now and expensive once the identifier is in an API, a database column and three dashboards.

A few conventions carry their weight. Booleans read best with a prefix that makes the question explicit - isActive, hasPermission, canEdit - because a bare active is ambiguous about whether it is a state or an action. Collections are plural and single items singular, so users and user rather than userList. Units belong in the name: timeoutMs, sizeBytes, priceCents.

Avoid abbreviating past the point of recognition. Two letters saved in usrMgr cost every future reader a moment, and search becomes unreliable when half the codebase writes user and the other half usr. The same applies to inconsistent synonyms: fetch, get, load and retrieve doing the same job in four modules is a small tax paid forever, and picking one is free.