Case Styles and Naming Conventions Explained

The Common Styles

camelCase is sometimes called lower camel case and PascalCase upper camel case. CONSTANT_CASE is also known as screaming snake case.

Which Style Each Language and Format Expects

Most ecosystems settled on a convention long ago, and following it makes code easier to read for everyone who knows that ecosystem:

kebab-case cannot be used for variable names in most programming languages, because the hyphen is read as a minus sign: order-total means order minus total.

Acronyms and Numbers

Acronyms are where conventions disagree most. One school keeps them in capitals (userID, parseHTML); another treats them as ordinary words (userId, parseHtml). Google's Java and JavaScript style guides take the second approach, which keeps word boundaries clear when acronyms meet: XmlHttpRequest is easier to split than XMLHTTPRequest. Microsoft's .NET guidelines keep two-letter acronyms in capitals (IOStream) and capitalise only the first letter of longer ones (HtmlButton). The browser API XMLHttpRequest mixes both, which is why it is often quoted as a warning.

Numbers have no case, so a converter cannot tell whether utf8Decoder means "utf8 decoder" or "utf 8 decoder". Converters usually attach a number to the word before it. Pick one spelling and use it everywhere.

Title Case and Sentence Case in Headings

In headings, style guides do not capitalise every word the same way. AP and Chicago style keep short articles, conjunctions and prepositions in lower case unless they come first or last ("The Lord of the Rings"), and they differ on the exact list. Many interface and documentation guides, including Microsoft's and Google's developer documentation guides, use sentence case instead ("Change your password"), which is easier to apply consistently and reads less formally.

The LeedyBox converter's Title Case capitalises every word, which is right for labels and variable-like names but not for a newspaper-style headline: lower the small words by hand afterwards.

Converting Between Styles Loses Information

Every conversion first splits a name into words, using capital letters and separators as clues, and then joins the words in the new style. Whatever the target style cannot express is gone: parseHTML becomes parse_html, and converting back gives parseHtml. Punctuation is dropped too, so "don't" turns into two words.

So treat one style as the source of truth. If a database uses snake_case and the code uses camelCase, convert at the boundary every time, in the same direction, rather than storing names in both forms.

Renaming Keys Across an API Boundary

When a front end in camelCase talks to a back end in snake_case, most serialization libraries can map the names automatically, so the data is never renamed by hand. Converting a JSON document once, for example a fixture or a sample response, is a different job, and the case converter's "JSON keys" mode does it without touching the values.

Watch for collisions: user_name and userName become the same key in either style, and one of them would overwrite the other. Leading symbols such as _id or $ref often carry meaning for a specific database or schema, so check whether they may be renamed at all.

Upper and Lower Case Beyond English

Case rules are not the same in every language. German ß becomes SS in upper case, so the word gets longer. Turkish has a dotted and a dotless i: its upper-case pair is i → İ and ı → I, while the default rule used by most programming languages turns i into I. JavaScript's toUpperCase() uses the default rule; toLocaleUpperCase('tr') applies the Turkish one. Korean, Chinese and Japanese have no upper and lower case at all, so only the separators between words change.

Case can also matter for file names. Windows and, by default, macOS treat Readme.md and README.md as the same file, while Linux treats them as two. A rename that only changes case can therefore go unnoticed on one system and break links or imports on another.

Frequently Asked Questions