String Case Converter

Converting cases as part of a refactor

Renaming identifiers across a codebase is rarely a one-off — it usually happens when adopting a linter rule or moving code between languages. A practical workflow: copy the identifier list out of your linter report (ESLint’s camelcase rule, PEP 8’s invalid-name from pylint), paste the list here one per line, convert, and use your editor’s multi-cursor or a sed script to apply the renames. Converting the names first and reviewing them as plain text catches awkward results — like an acronym that splits badly — before they touch the code.

Edge cases worth knowing

• Numbers stick to the word before them: user2fa → user_2fa in snake_case, keeping the digit grouped with its suffix.
• Mixed separators (hello_world-FooBar) are normalized in one pass; you don’t need to pre-clean the input.
• Title Case follows headline conventions: every word is capitalized. For AP-style headlines where short conjunctions stay lowercase, do a manual pass afterwards — automated AP capitalization requires a dictionary of minor words.
• SCREAMING_SNAKE_CASE is just snake_case + UPPER: convert to snake_case first, then apply UPPERCASE if you need constant style.

Where each convention is expected

Beyond per-language norms, casing matters at system boundaries: REST APIs conventionally use snake_case or camelCase JSON keys (pick one and stay consistent), environment variables are SCREAMING_SNAKE_CASE by POSIX convention, CSS custom properties and HTML data attributes must be kebab-case (HTML attribute names are case-insensitive), and database identifiers are safest in snake_case because unquoted identifiers fold to lowercase in PostgreSQL and uppercase in Oracle. Converting at these boundaries — rather than letting two conventions leak into one layer — is what keeps serializers and ORMs configuration-free.