Nobody argues that one naming convention is objectively better. They argue about which one belongs where, and that question does have answers — not because of aesthetics, but because each convention became dominant in a particular context for a reason, and following the local convention is what makes code readable to the people who maintain it.
The five conventions
camelCase — getUserName. First word lowercase, subsequent words capitalised. The standard for variables and functions in JavaScript, Java and C#, and for keys in JSON.
PascalCase — UserAccount. Every word capitalised, including the first. Used for classes, types and components in most languages that use camelCase for variables. The distinction is deliberate: a capital first letter signals "this is a type, not a value."
snake_case — get_user_name. Lowercase with underscores. The convention in Python, Ruby, Rust and PHP function names, and near-universal for SQL table and column names.
kebab-case — user-account. Lowercase with hyphens. Used for URLs, CSS class names, HTML attributes and file names. Notably it cannot be used for identifiers in most programming languages, because the hyphen is the subtraction operator.
CONSTANT_CASE — MAX_RETRY_COUNT. Uppercase with underscores. Constants and environment variables, essentially everywhere.
Why the divisions exist
Some of it is historical accident. C used underscores, so the Unix and systems programming world did too, and Python inherited that lineage. Java arrived with camelCase in its standard library, and JavaScript followed Java's surface conventions closely enough to inherit it.
But some of it is technical, and those cases are the ones worth knowing.
URLs use hyphens because search engines treat them as word separators. Google has stated this directly: a hyphen separates words, an underscore joins them. So user_account in a URL is read as one token that nobody searches for, while user-account is read as two words. This is not a style preference; it has measurable consequences.
CSS uses hyphens because the language does. Every built-in CSS property is hyphenated — background-color, font-size. Class names in camelCase look foreign in a stylesheet for that reason.
SQL uses underscores because of case handling. SQL identifiers are case-insensitive in most engines and are often folded to one case automatically. A column named userName may come back as username, at which point the camel hump has bought you nothing. Underscores survive the folding.
Constants are uppercase for visibility. The convention exists so that a reader scanning code can tell at a glance that a value will not change, without looking up its declaration.
The boundary problem
Where these conventions meet is where the friction appears, and every real project has such a boundary.
Your database uses snake_case. Your API returns JSON with camelCase keys. Your CSS classes are kebab-case. The same conceptual field — a user's date of birth — is date_of_birth, dateOfBirth and date-of-birth depending on which layer you are in.
Two approaches. Either convert at the boundary, so each layer stays internally consistent and a mapping layer translates — this is what most ORMs and serialisation libraries do automatically. Or pick one convention and use it everywhere, accepting that it will look wrong in some layers. The first is more work to set up and much more comfortable to live in.
What you should not do is convert inconsistently, so that some fields are translated and some are not. That produces the worst outcome: nobody can predict what a field is called without looking.
Acronyms: the unsolved problem
Every convention breaks down on acronyms and none of the answers is satisfying.
Is it parseHTMLDocument or parseHtmlDocument? getURLPath or getUrlPath?
Microsoft's guidance for C# says capitalise two-letter acronyms fully and treat longer ones as words — IOStream but HtmlParser. Google's Java style guide says treat every acronym as a word: parseHtmlDocument. That is the more consistent rule and the easier one to apply mechanically.
It also matters for conversion. Automated tools split on capital letters, so parseHTMLDocument becomes parse_h_t_m_l_document — every letter of the acronym read as a separate word. Writing acronyms as words avoids this entirely, which is a practical argument for the Google rule.
Converting in bulk
Porting code between languages, generating SQL columns from JSON keys, or renaming a set of files usually means converting a list of names rather than one. Our Case Converter handles all five conventions and processes each line separately, so a whole column of names converts in one pass. It reads existing capitals as word boundaries, so conversion works in any direction.
The acronym caveat above applies to it as it does to every such tool — those need a manual pass afterwards.
Quick reference
- JavaScript, Java, C# — camelCase for variables and functions, PascalCase for classes
- Python, Ruby, Rust — snake_case for variables and functions, PascalCase for classes
- SQL — snake_case for tables and columns
- URLs, CSS, HTML attributes — kebab-case
- Constants and environment variables — CONSTANT_CASE
- JSON — camelCase by convention, though the format imposes nothing
