Case conversion and naming

Migrate Camel, Snake and Kebab Names Without Collisions

Plan a naming migration with an explicit old-to-new mapping, acronym and digit rules, collision checks, and tests for dependent references.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Migrate Camel, Snake and Kebab Names Without Collisions

Changing camelCase, snake_case and kebab-case names across a project is a migration, not merely a formatting pass. Start with a complete list of existing names, define the destination rule and calculate the proposed names without replacing anything. Then check collisions and dependent references before applying the change.

Build a reviewable mapping

For a small example, suppose three source labels are user-name, user name and accountID. Converting them with the Snake Case Converter gives user_name, user_name and account_id. The first two labels collide even though the third converts cleanly. A mapping table exposes that problem before any data is overwritten.

Original name	Proposed name	Decision needed
user-name	user_name	Shares its output with another label
user name	user_name	Choose a distinct approved name
accountID	account_id	Check consumers of the old spelling

Do not resolve a collision by silently keeping whichever record appears first. Decide whether the labels refer to one concept or separate concepts. If they are separate, choose distinct names and record that decision so the transformation can be reviewed and repeated.

Write the acronym and digit policy

The local converter turns HTTPServer2 into http_server_2. The corresponding camel and kebab outputs are httpServer2 and http-server-2. A project that wants server2 to remain one token needs a different rule or a reviewed override. The distinction can affect generated client fields and file names.

Specify whether all acronyms become ordinary words, whether leading digits are allowed, and whether existing separators are normalized. Also decide how names containing non-English letters should be handled. An ASCII-only receiver may reject a valid Unicode output; removing those letters blindly can create additional collisions.

Find references beyond the declaration

A variable rename can affect imports, property access, tests, documentation and generated files. A data-field rename may affect database columns, request payloads, saved exports and clients outside the current repository. Search for the original name and identify whether each occurrence is executable code, a string contract or explanatory text.

Use a language-aware refactoring tool for symbols when available. Plain text replacement cannot reliably distinguish a variable from a quoted example or a larger identifier that happens to contain the same characters. Review the proposed diff and keep automated generators synchronized with their source definitions.

Plan externally visible changes separately

If other users or systems depend on an old field or route, decide how they will transition before publishing a replacement. A conversion utility does not authorize removing the existing interface. Keep compatibility behavior deliberate and test both the established name and the new name where the migration plan requires them.

For local working files, write converted output into a separate directory or document first. Preserve the mapping and the original files until acceptance checks pass. Renaming a file can also affect links that contain its exact name, even when the file’s contents are unchanged.

Test the mapping and its consumers

Check that every source name has one reviewed destination and that no unexpected duplicate destinations remain. Include a known collision such as user-name versus user name in the tests. A test suite containing only easy names cannot demonstrate that collision detection works.

Run the receiving parser, linter or application against the proposed output. For a JSON export, check exact property names and representative values after loading it. For code, exercise an affected call site as well as compiling or parsing the declaration. A syntactically valid name can still be the wrong contract.

Retain enough information to undo the migration

Keep the original-to-final mapping with the change record. Do not expect a second case conversion to recover the original spelling: spaces, hyphens and acronym capitalization may already have been discarded. Restore from the saved source or version history when a reviewed name must be changed again.

Naming context

JavaScript’s identifier grammar describes syntax constraints. The actual naming convention and migration compatibility policy belong to the receiving project.