A naming convention is the agreed way to join words into a single identifier, because most programming languages do not allow spaces in names. The phrase "user account settings" can become userAccountSettings, UserAccountSettings, user_account_settings, user-account-settings, or USER_ACCOUNT_SETTINGS depending on the language and on what the name refers to. None of these is more correct than the others. What matters is matching the convention of the language you are writing in, so your code reads like the rest of its ecosystem.
The Six Conventions at a Glance
| Convention | "user account settings" | Typical use |
|---|---|---|
| camelCase | userAccountSettings | Variables and functions in JavaScript and Java; local variables in C# |
| PascalCase | UserAccountSettings | Classes and types in almost every language; methods in C# |
| snake_case | user_account_settings | Variables and functions in Python, Ruby, and Rust; many database columns |
| SCREAMING_SNAKE_CASE | USER_ACCOUNT_SETTINGS | Constants in Python, Java, Rust, PHP, and Ruby |
| kebab-case | user-account-settings | CSS class names, URLs, command-line flags, file names on the web |
| dot.case | user.account.settings | Configuration keys and some package or namespace names |
You can generate most of these with the converters on this site: camelCase, snake_case, kebab-case, dot.case, and UPPERCASE (run snake_case first, then uppercase it, for SCREAMING_SNAKE_CASE).
What Each Language Recommends
Most mainstream languages publish an official or widely adopted style guide. This table summarizes what each one says for the three most common kinds of names.
| Language | Variables and functions | Classes and types | Constants | Source |
|---|---|---|---|---|
| Python | snake_case | PascalCase ("CapWords") | SCREAMING_SNAKE_CASE | PEP 8 |
| Java | camelCase | PascalCase | SCREAMING_SNAKE_CASE | Google Java Style Guide |
| C# | camelCase for locals and parameters; PascalCase for methods and public members | PascalCase | PascalCase | Microsoft Learn |
| Rust | snake_case | PascalCase ("UpperCamelCase") | SCREAMING_SNAKE_CASE | Rust API Guidelines |
| Go | camelCase, or PascalCase to export | PascalCase to export, camelCase if unexported | Same as other names (no underscores) | Effective Go |
| PHP | camelCase for methods | PascalCase ("StudlyCaps") | SCREAMING_SNAKE_CASE | PSR-1 |
| JavaScript | camelCase | PascalCase | Often SCREAMING_SNAKE_CASE for fixed values | Common convention (no single official guide) |
Two details are worth knowing. In Go, capitalization is not just style: a name that starts with a capital letter is exported from its package, and a lowercase one is private. In C#, Microsoft's guide also prefixes private fields with an underscore (_userAccount).
Conventions on the Web
- CSS: property names are kebab-case by definition (
background-color), and most teams use kebab-case for class names and custom properties to match. - URLs: Google recommends hyphens rather than underscores to separate words in URLs, which is why slugs like
user-account-settingsare the norm. The spaces to hyphens converter builds them. - JSON and APIs: there is no standard. JavaScript-centric APIs usually use camelCase keys, while many Python and Ruby APIs use snake_case. Pick one per API and keep it.
- Databases: SQL has no official rule, but lowercase snake_case for table and column names is common because many databases fold unquoted identifiers to a single case.
Converting Between Conventions
Every convention above is the same list of words joined differently, so converting is mechanical:
- Split the name into words (at capitals, underscores, hyphens, or dots).
- Lowercase every word.
- Join them with the target rule: capitalize each word after the first for camelCase, every word for PascalCase, or join with "_", "-", or "." for snake, kebab, or dot case.
Acronyms are the usual stumbling block. Most modern style guides, including Google's Java guide and Microsoft's .NET guidance, treat an acronym as a normal word in camelCase and PascalCase, so you get parseHtml and XmlReader rather than parseHTML and XMLReader.
Picking a Convention
Follow the language first, then your codebase. If a project already mixes conventions, match the file you are editing rather than reformatting everything at once. Linters can enforce the choice automatically: the Rust compiler warns about non-snake-case function names by default, and tools like ESLint and Pylint have naming rules you can switch on.
Naming conventions are a separate question from capitalizing headings and titles. For those, see the title case styles comparison or the title case converter.