camelCase, snake_case, and kebab-case: Why Programmers Cannot Agree on a Simple Naming Rule

Why Programming Names Cannot Have Spaces

Every programming language has a rule that variable and function names must be single tokens without spaces. Python cannot parse user name = 5 as a variable assignment. The name user name is two tokens, not one. Every language requires the same thing: a name must be parseable as a single unit.

Human language has no such constraint. Spoken language relies on intonation and context. Written language uses spaces freely. When programmers needed to write multi-word identifiers, they had to choose a convention for representing word boundaries without spaces.

The most common conventions that emerged are: camelCase (where each word after the first starts with a capital letter, as in myVariableName), PascalCase or UpperCamelCase (where every word starts with a capital, as in MyClassName), snake_case (where words are separated by underscores, as in my_variable_name), and kebab-case (where words are separated by hyphens, as in my-variable-name).

The names of the naming conventions are themselves revealing. camelCase refers to the humps created by the capital letters mid-word. snake_case refers to the flat, low appearance of underscored text. kebab-case, sometimes called spinal-case, refers to items skewered on a kebab by the hyphens. SCREAMING_SNAKE_CASE adds all-caps for constants. The names were coined informally over years of internet programming discourse.

How Each Language Community Chose Its Convention

Why different programming communities chose different conventions traces back to each language's heritage and community culture, not any objective advantage of one convention over another.

The camelCase style has a specific origin: it was established at Xerox PARC around 1978 with the Mesa programming language, which was developed for the Xerox Alto computer. The Alto lacked an underscore key on its keyboard, and spaces were not permitted in identifiers. With underscores unavailable, camelCase emerged as the practical solution. The PARC Mesa Language Manual of 1979 included a formal coding standard specifying both upper and lower camelCase rules. The Smalltalk language, which was also developed on the Alto and spread widely in the early 1980s, carried the convention outside PARC. The term "camel case" itself did not appear in writing until 1995, in a Usenet post by Newton Love.

C, developed at Bell Labs in the early 1970s, used predominantly lowercase with underscores: printf, malloc, strlen. The Unix operating system, written in C, followed the same pattern. This established a strong convention in systems programming communities that persists today. Python, which positioned itself as a readable language and drew on Unix and C traditions, adopted snake_case as its official convention in PEP 8, the style guide published by Guido van Rossum in 2001.

Java, developed at Sun Microsystems in the mid-1990s, used camelCase for variable and method names and PascalCase for class names, following the Xerox-PARC-to-Smalltalk lineage. This convention became entrenched because Java's standard library uses it throughout, and programmers who learn any language absorb the conventions of its standard library. JavaScript, which borrowed Java's name and several of its conventions, also adopted camelCase and has largely maintained it.

C# followed Java's conventions when Microsoft released it in 2000, partly to attract Java programmers. C++ has no dominant convention because it predates the era of community-enforced style guides and is used across too many domains to have converged on one.

The result of this history is that switching between languages requires mentally shifting naming gears. A Python programmer writing JavaScript must retrain their automatic spelling. A JavaScript programmer contributing to a Python project faces the same friction in reverse. Linters and formatters in each ecosystem can automatically enforce the correct convention, but humans typing by intuition still make mistakes.

Why kebab-case Exists in CSS but Not in Code

Kebab-case occupies a special position: it is the most common convention for HTML attributes (data-user-id), CSS class names (button-primary), and URL slugs (/blog/my-article-title), but it cannot be used in most programming languages because hyphens are subtraction operators. a-b in code means a minus b, not a-b as a name. This accident of syntax has created a permanent fork: the web's presentational layer uses hyphens, and its logic layer cannot.

The practical case for text case converters is exactly this fragmentation. A developer taking a concept name from a design document might need it as PascalCase for a React component, camelCase for a JavaScript function, snake_case for a Python variable, and kebab-case for a CSS class. The same semantic concept, perhaps "user profile card," becomes UserProfileCard, userProfileCard, user_profile_card, and user-profile-card depending on context. Manually converting between these is fast enough for one name but tedious enough across an entire codebase or API design session that automation earns its existence.

Database naming also presents a common case for conversion. Database column names often arrive in snake_case from PostgreSQL or MySQL schema definitions. Application code may expect camelCase property names. ORMs handle some of this mapping automatically, but ad-hoc queries, API designs, and migration scripts still require humans to translate between the conventions.

Conclusion

Naming conventions are not rational design decisions. They are the accumulated residue of language community culture, standard library choices, and the particular constraints of each language's syntax. The hyphens are for CSS. The underscores are for Python. The humps are for Java. The capitalized starts are for classes.

The Text Case Converter at ToolHQ converts between camelCase, PascalCase, snake_case, kebab-case, UPPER CASE, lower case, Title Case, and Sentence case instantly. Paste in any text and convert to the format your current context requires.

Frequently Asked Questions

Try These Free Tools