camelCase

The origin of camelCase

The name camelCase refers to the visual silhouette of the convention: capital letters rising like humps from a lowercase baseline. The pattern predates modern programming — it appeared in trademarks like CinemaScope and NyQuil long before any compiler existed — but it became canonical for variable naming in the 1970s and 80s as identifiers in languages like C and Pascal began allowing mixed case.

The breakthrough was practical. Early programming languages either forced uppercase (FORTRAN, COBOL) or accepted any case but stripped meaning (BASIC). When Smalltalk-72 and later Smalltalk-80 popularized mixed-case identifiers that preserved both readability and word boundaries, camelCase emerged as a workable compromise: shorter than snake_case, more readable than alllowercase, easier to type than PascalCase for non-class entities.

Where camelCase is the standard today

camelCase remains the dominant convention for variables, methods, parameters, and properties in most C-family and JVM languages:

• JavaScript and TypeScript: nearly universal for variables, functions, and object properties. const userName, function getCurrentUser(), obj.firstName.
• Java: the Java Language Specification mandates camelCase for methods and variables. Class names use PascalCase, but everything inside uses camelCase.
• C# and .NET: camelCase for local variables and method parameters; PascalCase for public methods, properties, and types. The mixed convention is one of the language's defining style choices.
• Swift and Kotlin: follow the JVM/Cocoa traditions of camelCase for instance methods and properties.
• Objective-C: the original modern home of camelCase. Even verbose method names like tableView:numberOfRowsInSection: follow the convention.

Common conversion pitfalls

The hard part of camelCase conversion isn't the format itself — it's correctly identifying word boundaries in the input. A naive converter that capitalizes every character after a space or underscore will mangle anything more interesting than three lowercase words.

Consider these inputs and what should happen:

• XML HTTP request → should produce xmlHttpRequest, not xMLHTTPRequest. ALLCAPS runs are single semantic units (acronyms) that should be lowercased except for the first letter when they're not the first word.
• iPhone Settings → should produce iPhoneSettings, preserving the brand's intentional internal capital.
• parse HTML5 document → should produce parseHtml5Document, treating the numeric suffix as part of the preceding token.
• get_user_id_from_url → should produce getUserIdFromUrl, even though the input is already lowercased.

Our converter tokenizes the input before reformatting. It recognizes acronym runs, numeric suffixes, brand exceptions, and existing case boundaries — so the conversion preserves semantic structure rather than mechanically capitalizing characters.

camelCase versus PascalCase

The two conventions differ only in the first character. camelCase starts lowercase; PascalCase starts uppercase. In languages that distinguish them (C#, Java, Swift), the difference signals meaning: camelCase identifies instances, variables, and methods; PascalCase identifies types, classes, and constants-by-convention.

JavaScript uses both: PascalCase for constructor functions and React components, camelCase for everything else. The distinction is a coding convention, not a language rule — JavaScript itself doesn't care — but the convention is universally followed in modern codebases.

When camelCase is the wrong choice

camelCase fails in three contexts: case-insensitive identifiers (SQL column names, where userName and username are the same identifier in most databases), URL paths (where mixed case creates confusion and is sometimes case-sensitive on Linux servers but not Windows), and environments where word boundaries need to be visually obvious (configuration files, environment variables, command-line flags). For these, snake_case, kebab-case, or CONSTANT_CASE are better choices.

For JSON keys, the convention varies. Google's JSON style guide recommends camelCase. Many REST APIs use snake_case because it matches their database column names. Pick one and apply it consistently — what matters is the absence of mixed conventions inside a single document.