One Feature Name, Four Naming Conventions: A Worked Example

Adding a new field to a real application rarely means naming it once. A feature like "order total value" typically needs a JavaScript variable, a database column, an environment variable if it is configurable, and a URL-friendly slug if it shows up in a route or a query parameter - four names, four conventions, and the same three words underneath every one of them.

Where each one goes

orderTotalValue in camelCase is the variable name in the JavaScript or TypeScript code that reads and displays the value. order_total_value in snake_case is the database column name, matching the convention most SQL schemas use even in an otherwise camelCase-heavy JS codebase - a real, common split that exists precisely because the frontend and the database layer have different, equally valid conventions. ORDER_TOTAL_VALUE in CONSTANT_CASE is what the same field becomes if it is ever configurable through an environment variable - a tax rate override, a currency default. order-total-value in kebab-case is the shape it takes in a URL path or a CSS class, where underscores and camelCase are both technically legal in a URL but violate the convention every routing guide and CSS style guide actually follows.

Where the manual version breaks

Typing all four by hand from the same three words is exactly the kind of repetitive, mechanical task where a small slip goes unnoticed. order_total_value retyped as order_totalvalue in a migration file will run without any error - it just creates a column with a name that never matches what the application code queries for, and the mismatch surfaces later as a confusing "column not found" error nowhere near the line that actually caused it. The same risk applies to a mistyped environment variable name: the app silently falls back to whatever default it has for a missing config key, and the bug hides until someone specifically checks whether the override is taking effect.

Converting instead of retyping

Starting from one phrase and converting it with the case converter removes the retyping step entirely: paste "order total value" once, then switch modes to get each variant in turn, all sourced from the exact same three words. The word-boundary logic behind camelCase, snake_case, kebab-case and CONSTANT_CASE is shared across all four modes, so the four outputs are guaranteed to agree with each other on where the word boundaries actually are - something that is easy to get subtly wrong typing each one from memory separately.

A second example makes the pattern more obvious: "Shipping Address Line 2" - a phrase with a trailing digit, the kind of field name that trips up a hand-typed conversion because it's easy to forget whether the digit gets its own separator. Converted, it becomes shippingAddressLine2, shipping_address_line_2, SHIPPING_ADDRESS_LINE_2 and shipping-address-line-2 - the digit is its own word in every mode - joined directly in camelCase, after an underscore or hyphen in the others - consistently, because the same tokenizer decides that boundary once and every mode reuses the result.

Why this is worth catching before code review, not during it

A mismatched name usually doesn't fail loudly. It fails as a silent undefined, a migration that runs clean but creates the wrong column, or an environment variable that quietly falls back to a default because the app is looking for a slightly different spelling than the one actually set. Those bugs get found eventually, but almost always later and by someone other than the person who made the typo - which makes them more expensive than a five-minute naming pass would have been, precisely because they surface far from where the actual mistake happened.

All of this happens in your browser - the phrase you are converting never leaves the page, whether it is a real feature name or a placeholder you are testing with.