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_2fain 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.