camelCase, snake_case, and where each belongs

The naming conventions look like taste and are mostly constraint. Kebab-case cannot be a variable name in most languages because the hyphen is the subtraction operator, so a name containing one parses as an expression rather than an identifier.

That is why the hyphenated form lives in the places where nothing is being parsed as code — URLs, CSS, filenames — and the underscore and capital forms live everywhere else.

Which form goes where?

The conventions are strong enough that violating them reads as an error.

The capitalised form marking a type rather than a value is the most consistently observed of these. In a language that follows it, seeing a capital first letter tells you what kind of thing a name refers to before reading anything else.

Constants in upper case with underscores is nearly universal, including in languages that use camel case for everything else. It survives because it is unmistakable.

Why do databases prefer underscores?

Because unquoted identifiers get case-folded, and the folding is not consistent between systems. One major database lowercases unquoted names, another uppercases them — so a column created as userName may come back as username or USERNAME depending on where it lives.

Once folded, a camel-cased name is indistinguishable from its lowercased form, and the only way to preserve the capitals is to quote the identifier everywhere it appears. That is a permanent tax on every query.

Using underscores sidesteps it entirely. The name survives folding unchanged, quoting is never needed, and the convention is old enough that it reads as normal to everyone.

Do these conversions round-trip?

Not reliably, and acronyms are why. Converting a name containing an acronym to underscores and back loses the original capitalisation, because the underscore form does not record where the acronym boundaries were.

A name like parseHTMLDocument becomes parse_html_document, and converting back produces parseHtmlDocument — correct by the rule, different from what was there. Whether that matters depends on whether anything compares the two.

Digits are the other ambiguous case. Whether a boundary falls before a number is a convention rather than a rule, so tools disagree about whether version2Handler becomes version2_handler or version_2_handler.

What about the interface between layers?

It is where most of this conversion happens. A database using underscores talking to an application using camel case needs a mapping, and doing it in one place is the difference between a convention and a mess.

The same applies at an API boundary. A payload using one convention consumed by code using another should be converted at the edge, so that neither side has to know about the other’s style.

Doing it inconsistently is the failure mode. A codebase where some fields were converted and some were not is worse than one that picked either convention and kept it.

Which form for a URL?

Hyphens, lowercase, no underscores. Hyphens are the long-standing convention for separating words in a URL, and lowercase avoids the question of whether a server treats paths case-sensitively — which some do and some do not.

The same argument applies to filenames in anything that will be served or shared. A file named with spaces or capitals works locally and causes small persistent problems everywhere else.

Environment variables are the opposite corner: upper case with underscores, because that is what shells and configuration systems expect, and a lowercase one looks like a mistake even where it works.

What about names that are not words?

Abbreviations and initialisms are where conventions break down, because a converter cannot tell an acronym from an ordinary word. Modern style guides increasingly treat acronyms as words precisely to remove the ambiguity, which makes conversion reversible again.

Single-letter prefixes are the other survival from an older era. Notations that encoded a variable’s type into its name solved a real problem in editors that could not tell you the type, and they persist mainly in codebases old enough to predate that.

The rule that has aged best is that a name should be readable aloud. Anything that cannot be said in a conversation about the code is a name that will be misread.

Questions people ask

Do file names follow the same rules? Lowercase with hyphens travels best. Spaces and capitals work locally and cause small persistent problems elsewhere.

Should constants always shout? In most languages, yes, and the convention is strong enough that a lowercase constant reads as a variable someone forgot to protect.

Is there a right answer? Within one language, yes — follow its convention. Across languages, no.

What about acronyms in camelCase? Most modern style guides treat them as ordinary words, so parseHtml rather than parseHTML.

Does a converter know the boundaries? It infers them from capitals, underscores and hyphens. A name that already mixes conventions confuses it.

Why is the capitalised form used for classes? Convention rather than requirement, and it is consistent enough that following it makes code readable at a glance.

Convert at the boundary, once. The camelCase, PascalCase, snake_case and kebab-case converters each produce one form, swap case and alternating case cover the other two transformations, and the Excel column letter to number converter handles the one naming scheme that is arithmetic rather than style.