lowerCamelCase versus PascalCase
lowerCamelCase starts the first word in lowercase and capitalizes later words, common for fields and variables.
PascalCase capitalizes the first word as well and is common for classes and types.
- GRN_FEE_AMT → grnFeeAmt
- GRN_FEE_AMT → GrnFeeAmt
Batch conversion of database columns
Enter one column per line to preserve source order. Confirm that input and output line counts match.
Spaces, hyphens, and underscores act as delimiters, so SELL-CLIENT-CD and SELL_CLIENT_CD can normalize identically.
Review acronyms and numbers
API_URL or IP_ADDR may become ApiUrl or IpAddr because acronyms are treated as ordinary words. Adjust the result if your project preserves forms such as apiURL.
Test names containing numbers and already-camel input before converting a large list.
Checks before changing code
Changing only a DTO field without its getters, setters, mappers, and JSON keys can break integration. Search the whole project for references.
The converted output is a convenient draft; team conventions and external API contracts remain authoritative.
Agree naming rules across the project
Basic snake-to-camel conversion does not settle acronyms, numbers, and mixed capitalization. Decide whether user_id becomes userId or userID and api_url becomes apiUrl or apiURL. Document boundaries when database columns, API JSON, TypeScript models, and form fields use different conventions.
PascalCase commonly names classes and types while lowerCamelCase names properties, but the existing codebase comes first. Gather samples with reserved words, leading digits, repeated underscores, hyphens, spaces, and non-ASCII text. Confirm that generated names are valid identifiers in the target language.
- Agree ID, URL, and API acronym style
- Document mapping boundaries between layers
- Test reserved words, digits, and special characters
Convert a column list and review the output
Paste one column per line, choose lowerCamelCase or PascalCase, remove blank lines, and compare output row count with input. Confirm that related columns such as created_at and updated_at remain distinct as createdAt and updatedAt.
USER_ID, user__id, and user-id may all collapse to userId. Do not apply colliding outputs automatically. Distinguish SQL aliases and ORM serialization mapping from a physical database rename.
- Reconcile input and output row counts
- Detect duplicate identifiers after conversion
- Separate mapping from physical schema changes
Avoid common code-generation failures
A name such as 2fa_enabled may become 2faEnabled, which cannot be used directly as a JavaScript identifier. Reserved words such as class or default can also be problematic. Add a safe prefix or use string keys and explicit generator exceptions.
Case-insensitive filesystems and databases may treat userID and userId as conflicting. Renaming public API fields can break clients, so map at the boundary or follow a versioned migration with rollback and compatibility time.
- Check leading digits and reserved words
- Find names differing only by case
- Plan compatibility for public API changes
Test before applying and maintain the rules
Generate results for the whole schema and automatically test uniqueness, identifier validity, and acronym consistency. When regenerating ORM models, separately compare types, nullability, and defaults. Run formatting and type checks before applying a small initial batch.
Keep rules in the README or generator configuration and use them during column review. Manual edits will be lost on the next generation, so store exceptions and regression tests with the tooling. Treat converter output as a draft and back up production schemas before change.
- Test the complete schema, not a few examples
- Preserve ORM types, nullability, and defaults
- Manage rules, exceptions, and tests together