Why Programming Languages Disagree on camelCase vs snake_case
Joining a codebase that mixes myVariable and my_variable, and getting a code review comment about it, feels like a taste dispute, but it isn't. Every language has a strong opinion about myVariable versus my_variable. None of it is arbitrary preference. It's inherited lineage from specific decades, specific languages, and in one case, specific limitations of old terminal hardware.
snake_case traces to the plain-ASCII, Unix-era terminal world
C and the broader Unix tradition. And Python, where the convention was formalized explicitly in the PEP 8 style guide. Lean toward snake_case, an underscore-separated convention that traces partly to an era when terminals and printers made subtle case distinctions genuinely harder to read reliably, favoring plain, unambiguous ASCII word separation over relying on capitalization alone.
camelCase has a specific, citable origin in Smalltalk
camelCase is frequently credited to Smalltalk, an influential programming language from the 1970s and 80s often cited as an early popularizer of joining words by internal capitalization rather than punctuation. Sun Microsystems then formalized camelCase in its official Java coding conventions in the 1990s, and JavaScript inherited the convention by direct lineage: Brendan Eich created JavaScript in 1995 explicitly designed to look approachable to Java programmers, carrying the naming convention along with it.
Some languages mix conventions deliberately, as a signal
JavaScript itself doesn't use camelCase uniformly. It reserves PascalCase (capitalizing the very first letter too) specifically for constructor functions, classes, and components, while ordinary variables and functions stay camelCase. That's not inconsistency; it's a deliberate visual signal that a capitalized identifier is a type or class and should be treated differently, formalized enough that linters like ESLint enforce the distinction by default rather than treating it as a style suggestion.
That's also the honest answer to "why does this codebase mix conventions": it usually isn't inconsistency for its own sake. A typical project stacks multiple languages, JavaScript on the frontend, Python or SQL using snake_case on the backend, CSS using kebab-case throughout, so the mixing happens across layers, not because anyone abandoned a style guide within a single language.
So which convention should you actually use?
CSS property names and HTML attributes use kebab-case (hyphen-separated) instead of either alternative, reportedly because case-insensitive parsing contexts around HTML made relying on capitalization risky for consistent cross-browser behavior, while underscores had their own historical baggage in URLs and identifiers. The result is that a single modern web project routinely runs three different naming conventions side by side, each inherited from a different decade and a different technical constraint.
If the goal is fitting into an existing codebase, match what's already there rather than what you personally prefer: consistency inside one language matters more than which convention won. If the goal is starting something new, follow the ecosystem default, snake_case for Python, camelCase for JavaScript and Java, kebab-case for CSS and HTML, since linters, style guides, and other developers will all expect it. And if the goal is just converting a batch of names between conventions, that's a mechanical problem, not a taste one.
Convert your own text between eight common cases with the text case converter.