Move between languages long enough and you start to notice the patterns: JavaScript wants camelCase, Python wants snake_case, CSS wants kebab-case, and compiled languages reserve PascalCase for types and CONSTANT_CASE for module-level constants. These conventions are not arbitrary — each emerged from a specific language’s syntax, the typography of its era, and the typing discipline of its community. Understanding the history explains the conventions; understanding the conventions makes your code feel native to the language.

The Eight Common Conventions

Eight identifier casing styles appear regularly across modern languages and systems. The Case Converter can produce all eight from any input.

  • lowercase — all characters small. Used for some package names and folder names.
  • UPPER CASE — all characters capital. Used for emphasis, headings, and some constant conventions.
  • Title Case — first letter of every word capitalized. Used for book titles and class names in some languages.
  • Sentence case — only the first character capitalized. Used for prose.
  • camelCase — first word lowercase, subsequent words capitalized, no separator. The dominant JavaScript convention.
  • PascalCase — every word capitalized, no separator. Used for classes, types, and React components.
  • snake_case — all lowercase, words joined by underscores. The dominant Python and C convention.
  • kebab-case — all lowercase, words joined by hyphens. The CSS and URL convention.
  • CONSTANT_CASE — all uppercase, words joined by underscores. The compiled-language constant convention.

JavaScript and Java: camelCase Origins

camelCase emerged in the early 1970s as a workaround for one of the era’s typing constraints. The original C language has no concept of identifiers longer than a single word; standard practice in FORTRAN and early assembly was to use single-word names (FILENAME, BUFSIZE) and disambiguate at the call site. The need for multi-word identifiers grew with the size of programs, and the solution was to glue the words together without a separator.

Two early adopters bracketed the camelCase era. Smalltalk (1972) used camelCase for method names because it was readable in the smalltalk REPL and natural to type. Objective-C (1984) used it for message names because the colon syntax made readable names like objectForKey: essential. By the time JavaScript was created in 1995, camelCase was the convention in the browser world via Java applets, and the language’s design took it for granted.

JavaScript uses camelCase for variables, functions, object properties, and methods; PascalCase for classes and React components. The convention is enforced by linters (ESLint’s camelcase rule) and built into the standard library (getElementById, charCodeAt, Array.prototype.forEach). Java uses the same split: camelCase for variables and methods, PascalCase for classes and interfaces.

Python and C: snake_case Origins

snake_case predates camelCase by a few years. C, designed in 1972, used snake_case for function names (printf, strcmp, malloc) and CONSTANT_CASE for macros (EOF, NULL, INT_MAX). The convention arose because underscore was the only non-alphanumeric character available in early C identifiers without preprocessor treatment — hyphens are interpreted as subtraction, and periods are structure-access operators.

Python (1991) inherited snake_case from C and made it the language default. PEP 8, the official style guide, mandates snake_case for functions, variables, and module names; PascalCase for classes; CONSTANT_CASE for module-level constants. The Python community enforces this with autopep8, black, and ruff. Going against the convention produces visible linter errors in any competent Python project.

C, C++, and Rust continue to use snake_case for functions and variables. Ruby uses snake_case for methods and variables but PascalCase for classes and modules. Go uses camelCase for unexported names and PascalCase for exported names — the convention is enforced by the compiler’s visibility rules.

CSS and URLs: kebab-case Origins

Hyphens in CSS were not always available. CSS 1.0 (1996) declared that identifiers could contain the characters A-Z a-z 0-9 - and Unicode characters above U+00A0. The hyphen was chosen because it is universally typeable on all keyboards and natural to read. CSS 2.0 added the underscore to the grammar but most CSS authors avoided it because early browsers did not support it consistently.

URLs use kebab-case for similar reasons. Slugs like https://example.com/blog/case-conversion-explained are universally readable, copy-pasteable, and search-engine-friendly. CamelCase slugs are technically allowed but are harder to read and slower to type. Underscore slugs are read as word-separators but produce a “wall of underscores” that is harder to read than hyphens.

Outside of CSS and URLs, kebab-case appears in CLI flag names (--dry-run, --verbose) and in some functional-language conventions (Elixir uses snake_case for variables and kebab-case for atoms and module names).

CONSTANT_CASE: The Compile-Time Convention

CONSTANT_CASE emerged in C and C++ as a way to distinguish preprocessor macros from ordinary identifiers. The preprocessor (#define) was used to declare compile-time constants, and the convention of all-uppercase gave the compiler a way to warn when a macro was used in a context that expected a regular identifier. By the time const variables existed in C++, the convention had spread to all forms of compile-time constants and remained.

Java maintains the convention: public static final int MAX_VALUE = 100;. JavaScript uses it for module-level constants and environment variable names. Go uses it for exported constants. Rust uses it for constants and statics. The convention is so ingrained that violating it (e.g., a const in lowercase) is a recognized code smell in any of these languages.

PascalCase: The Type Convention

PascalCase (also called UpperCamelCase) is the standard for class names, type names, and React components. The convention emerged with object-oriented programming: Simula (1967) used it; Smalltalk (1972) used it; C++ (1985) used it; Java (1995) used it. By the time C# came around (2000), PascalCase was so strongly associated with class identifiers that Microsoft formalized it in the .NET Framework Design Guidelines.

The intuition is that type names are conceptually different from value identifiers: a UserAccount is a class, while a userAccount is an instance. The capitalization makes the distinction visible at the call site without needing to look up the identifier. JavaScript adopted PascalCase for classes in ES6 and for React components because the convention was already strong in the surrounding ecosystem.

Acronyms in PascalCase

One ongoing source of confusion is how to handle acronyms. Three conventions are in active use:

  • All caps, even in identifiers: XMLParser, URLConnection, HTTPServer. Common in the Java standard library (URLEncoder, HTTPClient).
  • Title case for the first letter only: XmlParser, UrlConnection, HttpServer. Common in .NET and modern Microsoft style guides.
  • All caps only at the start: XMLParser but parseXMLDocument (mid-word acronyms become lowercase). The Google style guide for most languages.

The choice is largely a matter of style guide; the most important thing is to pick one and apply it consistently. The Case Converter treats consecutive uppercase letters as a single acronym (so XMLParser round-trips correctly), but the convention for how to write the acronym in a different case is up to you.

Naming in Database Schemas

Databases have their own conventions. PostgreSQL defaults to lowercase identifiers (user_account) because it folds unquoted identifiers to lowercase. MySQL is case-sensitive on Linux but case-insensitive on macOS and Windows, leading to the standard convention of snake_case for portability. Microsoft SQL Server defaults to PascalCase (UserAccount) to match the .NET naming convention.

When you migrate data between databases or join columns across systems, case normalization is often the first step. The Case Converter is the right tool for one-off conversions; for batch normalization, a SQL script that applies LOWER(REPLACE(column_name, ' ', '_')) is the standard pattern.

Choosing a Convention for a New Project

Three rules of thumb for a new codebase:

  1. Follow the language default. JavaScript projects should use camelCase for variables and PascalCase for classes; Python projects should use snake_case. The lint configuration will catch violations soon enough.
  2. Use CONSTANT_CASE for compile-time constants. Across most languages this is universal. If you find yourself defining a constant in lowercase, you have probably misclassified it.
  3. Pick one convention for acronyms and stick to it. Either all-caps (XMLParser) or title-case (XmlParser); the choice is cosmetic but the consistency is not.

If you are maintaining an existing codebase, follow the dominant convention. Breaking style introduces friction for every future reader and reviewer. A 100,000-line camelCase codebase is not improved by adding snake_case functions; it is worsened.

The Bottom Line

Identifier naming conventions are load-bearing parts of a language’s culture. JavaScript’s camelCase, Python’s snake_case, CSS’s kebab-case, and CONSTANT_CASE for compiled constants are not arbitrary choices — each emerged from a specific history and is enforced by every serious linter in the language. Pick the convention that matches the language, apply it consistently, and use the Case Converter when you need to translate between conventions.

Further Reading

  • PEP 8 — Style Guide for Python Code, the canonical reference for snake_case identifiers in Python.
  • Google JavaScript Style Guide — the canonical JavaScript naming conventions, including the acronym rule.
  • .NET Framework Design Guidelines — Microsoft’s prescriptive naming conventions for .NET APIs.
  • Effective Java by Joshua Bloch — the classic reference for Java naming conventions (Item 56: Adhere to generally accepted naming conventions).
  • Airbnb JavaScript Style Guide — one of the most widely adopted JavaScript style guides, with explicit naming rules.

Frequently Asked Questions

Why is it called camelCase? The uppercase letter in the middle of the identifier (myVariable) evokes the hump of a camel. The term was popularized in the 1990s and is now universal.

Which is correct: camelCase or snake_case? Both. The choice depends on the language and the project. JavaScript ecosystems use camelCase; Python and C ecosystems use snake_case. The wrong choice is the one that does not match the language’s convention.

Is PascalCase the same as UpperCamelCase? Yes. PascalCase is the same style as camelCase, but with the first letter capitalized. Both terms are used; PascalCase is more common in modern style guides.

How do I handle acronyms in identifiers? Pick a convention. Java uses URLEncoder (all caps); .NET uses UrlEncoder (title case). The most important thing is to apply the same rule to every acronym in the same context.

What about numeric prefixes in identifiers? utf8, html5, iso8601 are common because the number is part of the standard name. The Case Converter keeps numbers attached to the preceding word, so html5Parser becomes html5_parser in snake_case.