The naming conventions and where each belongs
- camelCase — first word lowercase, subsequent words capitalised. JavaScript variables and functions, Java methods, JSON keys.
- PascalCase — every word capitalised. Class names, React components, type names.
- snake_case — lowercase with underscores. Python variables and functions, Ruby, most SQL column names.
- kebab-case — lowercase with hyphens. URLs, CSS class names, HTML attributes, file names.
- CONSTANT_CASE — uppercase with underscores. Constants and environment variables across nearly every language.
These are conventions, not rules the compiler enforces. Their value is entirely in consistency — a reader who knows the convention can infer what a name refers to before reading its definition.
Why the conventions differ by language
The differences are largely historical accident rather than design. Java popularised camelCase, Python's style guide specified snake_case, and C adopted uppercase constants early. Each community then held to its own.
The one convention with a technical basis is kebab-case in URLs and CSS. Underscores are not reliably visible in underlined link text, and search engine guidance has long treated hyphens as word separators while underscores are not. In CSS, hyphens are permitted in identifiers while camelCase would be confusing next to hyphenated property names.
The practical rule is to follow the convention of whatever you are writing, not your personal preference. Mixed conventions within one codebase are worse than any single convention consistently applied.
Where conversion actually gets used
API boundaries. A Python backend using snake_case talking to a JavaScript frontend using camelCase needs a translation layer. Most frameworks provide one, and doing it in one place is far better than scattering conversions through the code.
Database mapping. SQL columns are conventionally snake_case while object properties follow the host language, so ORMs perform this conversion constantly.
Configuration. Environment variables are CONSTANT_CASE by convention, while the config objects they populate use the language's own style.
Code generation. Tools generating clients from an API schema must map names into the target language's conventions.
Edge cases that break naive conversion
Case conversion looks trivial and is not. Several cases catch simple implementations:
- Acronyms. Is it
parseHTMLDocumentorparseHtmlDocument? Converting the first back to kebab-case naively givesparse-h-t-m-l-document. Most style guides now recommend treating acronyms as words. - Numbers. Should
address2becomeaddress_2oraddress2? Conventions differ. - Leading digits. Most languages forbid identifiers starting with a number.
- Non-ASCII characters. Uppercasing is locale-dependent — in Turkish, lowercase
iuppercases toİ, notI, which has caused real bugs in case-insensitive comparisons.
For that last reason, comparisons intended to be case-insensitive should use case folding rather than uppercasing, and locale-independent methods where available.
Title case, which is genuinely inconsistent
Title case has no single definition. The Chicago Manual of Style, AP, APA, and MLA all differ on which short words are capitalised and at what length.
Common ground: capitalise the first and last word, and all major words. Lowercase articles (a, an, the), short prepositions, and coordinating conjunctions when they fall in the middle. The disagreement is over where the preposition length cutoff sits — commonly three, four, or five letters.
The simple conversion offered here capitalises every word, which is adequate for headings and identifiers but not for editorial copy. For publication, follow whichever style guide the publication uses.
Frequently asked questions
What is the difference between camelCase and PascalCase?
camelCase starts with a lowercase letter (myVariable) while PascalCase capitalises every word including the first (MyClass). camelCase is conventional for variables, PascalCase for classes and types.
Why do URLs use hyphens instead of underscores?
Underscores are not reliably visible in underlined link text, and search engines have long treated hyphens as word separators while underscores are not.
How should acronyms be handled in camelCase?
Most modern style guides recommend treating them as ordinary words - parseHtmlDocument rather than parseHTMLDocument - because it survives conversion to other cases without producing nonsense.
Why can case conversion break for non-English text?
Uppercasing is locale-dependent. In Turkish, lowercase i uppercases to a dotted capital rather than I, which has caused real bugs in case-insensitive comparisons. Use case folding for comparison instead.