Case Converter

Naming conventions are shared contracts about how to structure identifiers. Rather than arbitrary style choices, each convention exists to solve a specific readability problem: camelCase removes spaces and uses capital letters as word boundaries, making it compact and unambiguous in languages where spaces aren't allowed in identifiers. snake_case uses underscores instead of capitals, which keeps every character lowercase and makes word boundaries explicit. kebab-case replaces spaces with hyphens, following the convention of URL paths and CSS class names.

PascalCase is camelCase with an initial capital — used for type names, class names, and any identifier that should read as a proper noun in the code. SCREAMING_SNAKE_CASE (all caps with underscores) is reserved for constants in most conventions, because the visual shouting signals 'this value does not change.' Title Case capitalizes every word and is used for human-readable strings like headings and labels, not typically for code identifiers.

camelCase starts lowercase and capitalizes the first letter of each subsequent word: myVariableName, getUserById, totalItemCount. The lowercase first letter signals 'this is a variable or function' in the conventions where PascalCase is reserved for types. This convention dominates JavaScript, Java, C#, and most modern languages — it's the default for variables, functions, and method names.

PascalCase capitalizes every word including the first: UserController, HttpResponse, DatabaseConnection. It's used for classes, interfaces, structs, and any user-defined type. The distinction between camelCase and PascalCase is not just cosmetic — it lets you read a line of code and immediately know whether you're looking at a value or a type, a function or a class, without checking a declaration.

snake_case uses underscores to separate words: user_name, max_retries, is_valid. It's the dominant convention in Python, Ruby, Rust, and C, and for database column names. The all-lowercase style makes identifiers visually distinct from camelCase types, which helps in polyglot codebases where Python services talk to JavaScript frontends — you can often tell which language a snippet came from just by the identifier style.

kebab-case uses hyphens: user-profile, main-navigation, submit-button. It's the convention for CSS class names, HTML attributes, and URL path segments. The hyphen is a natural word separator in written language, which makes kebab-case identifiers read almost like normal text. One gotcha: hyphens are subtraction operators in most languages, so kebab-case is not valid for code identifiers outside of languages that allow it in strings or attribute names.

While the conventions are broadly shared, each language community has its own specific rules. Python's PEP 8 prescribes snake_case for functions and variables, PascalCase for classes, and SCREAMING_SNAKE_CASE for constants. JavaScript and TypeScript follow camelCase for variables and functions, PascalCase for classes and React components. Java uses camelCase for everything except constants and class names. C# follows camelCase and PascalCase but also has a convention for interface names prefixed with I (IEnumerable, IDisposable) — a vestige of Hungarian notation that the language team has kept for its clarity.

The most important rule is consistency within a codebase. A project that mixes conventions randomly is harder to read than one that follows any single convention faithfully. When joining an existing project, match its conventions rather than imposing your own — the cognitive cost of switching between conventions across files is real, and readability is the entire point of having conventions at all.

Converting between naming conventions requires splitting a string into words first, then rejoining them with the target convention's separator and casing rules. The splitting step is where the real complexity lives: you need to handle spaces, hyphens, underscores, and case boundaries. A string like 'alreadyCamelCase' has no explicit separators — the word boundaries are implied by the capital letters. A robust converter detects transitions from lowercase to uppercase, treats consecutive capitals as a single acronym, and handles digit boundaries.

Edge cases abound. 'APIKey' should split into ['API', 'Key'] and become 'api_key' in snake_case — not 'a_p_i_key', which would happen if each capital were treated as a separate word. 'HTTPResponseCode' should become 'http_response_code'. 'user2FactorAuth' should become 'user_2_factor_auth' or 'user2_factor_auth' depending on how you handle the digit boundary. A good converter gets these cases right because they appear constantly in real codebases that mix acronym-heavy domain language with standard naming conventions.