Document Workflow

Rename identifiers safely across code, data, and routes

Plan a case-convention change without breaking API fields, database columns, imports, filenames, routes, selectors, acronyms, or external references.

Written and tested by Published: Reviewed:

How this workflow was checked

In Case Converter for camelCase, snake_case, and 8 More Styles, the “Review automatic candidates before a migration” fixture was run without repairing or simplifying its input. We verified the transition from “Write the destination naming policy” to “Review tokenization and warnings”, compared the final artifact or values, and reviewed “Changing an API or database key without a migration” plus “Accepting every acronym conversion” as non-success paths.

The converter proposed xmlHttpRequestId and 2026Release, while the review output kept the XMLHttp acronym decision and invalid leading-digit risk visible for manual approval.

Problem

Changing User Display Name to userDisplayName looks mechanical, but a real rename can cross source code, JSON payloads, database columns, CSV imports, CSS selectors, routes, filenames, environment variables, documentation, and external clients. A converter can produce consistent candidates; it cannot know whether API is written api or API, whether a leading number is legal, whether a case-insensitive filesystem will register a case-only rename, or whether an old URL needs a redirect. The safe workflow separates candidate generation from contract migration and proves the result in the system that will consume it.

When to use this

  • A team is adopting camelCase, snake_case, kebab-case, or PascalCase for an existing set of names.
  • Spreadsheet or CSV headers must map to database columns, JSON keys, or import fields with an explicit naming policy.
  • A route, CSS selector, package key, environment variable, filename, or directory name needs a consistent convention.
  • Mixed camel, acronym, space, hyphen, and underscore input must be reviewed as a batch without joining its lines.
  • A heading needs a mechanical capitalization candidate before a human applies the publication's actual editorial rules.

Steps

  1. Step 1

    Inventory the name as a contract

    Search source, tests, configuration, schemas, migrations, documentation, analytics, clients, and stored data. Mark which occurrences are internal and which require compatibility, aliases, redirects, or a staged migration.

  2. Step 2

    Write the destination naming policy

    Choose the case by context and record acronym, number, Unicode, reserved-word, and separator rules. Decide explicitly whether APIResponse should become apiResponse, api_response, or another project-approved form.

  3. Step 3

    Generate candidates from representative lines

    Paste one source name per line into the case converter. Keep the original order so every output line can be matched back to its source, and stay within the 2 MiB and 100,000-line limits.

  4. Step 4

    Review tokenization and warnings

    Check detected word counts, acronym normalization, punctuation-only lines, digit-leading outputs, and Unicode length changes. Compare UPPERCASE or lowercase when punctuation must remain literal.

  5. Step 5

    Resolve destination-specific invalid names

    Check reserved words, allowed identifier characters, maximum lengths, case sensitivity, filesystem restrictions, database quoting, and route encoding. Fix exceptions deliberately instead of adding one broad replacement rule.

  6. Step 6

    Apply the rename with a reviewable diff

    Use language-aware rename tooling where possible. For case-only file renames on a case-insensitive filesystem, use an intermediate filename. Compare the complete diff and avoid replacing values inside unrelated text or generated files.

  7. Step 7

    Verify compatibility in the destination

    Run tests, type checks, schema and import validation, link checks, builds, and target-platform execution. Preserve aliases, database migrations, API compatibility, or URL redirects until consumers and stored data have moved.

Example

Review automatic candidates before a migration

Input

XMLHttp request-id
2026 release

Output

camelCase candidates:
xmlHttpRequestId
2026Release

Review: confirm XMLHttp acronym policy; the second value begins with a digit and may be invalid.

Common mistakes

Running a global text replacement first

Blind replacement can alter comments, examples, serialized data, substrings, generated files, and unrelated names. Inventory and use syntax-aware rename support before narrow text replacement.

Changing an API or database key without a migration

Clients and stored records may still send or contain the old name. Add an alias, compatibility reader, schema migration, or versioned contract before removing it.

Accepting every acronym conversion

Automatic boundaries are deterministic, not project-aware. Review API, URL, ID, HTTP, OAuth, product names, and initialisms against the written policy.

Ignoring case-insensitive filesystems

A rename from userprofile.ts to UserProfile.ts may not register as expected. Rename through a temporary path and verify the committed file entry.

Publishing a mechanical Title Case result

Mechanical capitalization does not know small words, sentence boundaries, proper nouns, trademarks, or language rules. Treat it as an editing candidate, not finished copy.

FAQ

Should JavaScript property names always use camelCase?

Internal JavaScript names often do, but serialized keys may be fixed by an API or data contract. Preserve or map external keys rather than changing them only to match local style.

How should API, URL, ID, and OAuth be cased?

There is no universal automatic answer. Choose examples in the project style guide, apply them consistently, and review converter output because acronym boundaries are normalized mechanically.

Can I rename database columns with only the converted list?

No. Prepare a schema migration, update reads and writes, inspect indexes and queries, migrate stored data or compatibility views, and coordinate every application that consumes the schema.

What is the safe way to rename only the case of a file?

On a case-insensitive filesystem, rename the file to a distinct temporary name, commit or verify that step, then rename it to the final spelling. Check imports and the repository diff.

Does Unicode normalization happen during case conversion?

No normalization form is promised. Case mapping and word joining are separate from NFC, NFD, NFKC, or NFKD; inspect normalization deliberately when canonically equivalent names matter.

When is a converted heading ready to publish?

After a human checks sentence intent, small words, proper nouns, acronyms, trademarks, language rules, and the publication's style guide. Mechanical Title Case alone is not that review.