CamelCase vs underscores: Scientific showdown (2011)

Original Article ↗ Hacker News Discussion ↗

Programmers revisit the long-running question of how to separate words in identifiers—camelCase, snake_case, kebab-case, or even allowing spaces—arguing over readability, ergonomics, typing effort, and how easily code can be searched or parsed. Some cite studies suggesting small readability advantages in specific cases, but note that keyboard layout, personal physiology, and language syntax (e.g., infix operators, keywords, whitespace rules) heavily influence what feels “best.” A recurring theme is that consistency and alignment with each language’s established conventions usually matter more than any theoretically optimal naming style.

Identifier styles: camelCase vs snake_case

  • Many find snake_case easier to read; underscores act like “breathing space” between words.
  • Others prefer camelCase, claiming it’s equally or more readable, especially in expressions where variables, functions, and parameters stand out visually.
  • Several note that language conventions strongly shape preferences (e.g., starting in Java vs Python).
  • Some mix styles (e.g., CamelCase/PascalCase for types, snake_case for variables) and find that distinction helpful.
  • Studies mentioned: one follow-up suggests differences in find time mainly for 3‑word names; another (recalled from elsewhere) allegedly favored snake_case readability.

Hyphen / kebab-case and operator conflicts

  • Kebab-case is praised as aesthetically pleasing, ergonomic, and “objectively” better due to fewer keystrokes.
  • Main pushback: ambiguity with subtraction (a-b vs a - b), mutual-exclusion edge cases like a, b, a-b, and problems interoperating with languages that disallow hyphens (e.g., CSS vs JavaScript background-color → backgroundColor).
  • Some propose grammar rules (e.g., -b illegal) or better error messages to mitigate confusion.

Spaces and unconventional identifiers

  • Several explore allowing spaces in identifiers, citing historical precedents (Fortran, ALGOL) and SQL-style quoted identifiers.
  • Concerns: parsing ambiguity (especially with infix operators and ML-style application), loss of keywords for variable names, and more opportunities for subtle bugs.
  • Workarounds floated: using TAB or non-breaking spaces, special prefixes, or dots/commas as separators; many examples are acknowledged as more “fun” than practical.

Ergonomics, keyboards, and accessibility

  • Underscores are called a “double-pinky” and linked to RSI; others report no issue or different fingerings.
  • Keyboard layout matters: on some non-US layouts _ is easy and may invert any performance/comfort conclusions.
  • Tabs vs spaces briefly enters the discussion, with an argument that tabs are better accessibility “markup” for indentation.

Language conventions and interoperability

  • Strong theme: follow the dominant convention of each language and its standard library to avoid cognitive dissonance.
  • Cross-language work (e.g., camelCase code with snake_case SQL schemas, CSS vs JS) creates friction and translation/grep issues.
  • There is some frustration with inconsistent or legacy standard libraries (e.g., Python’s logging), and with acronym capitalization rules in CamelCase/PascalCase.

Historical, aesthetic, and tooling angles

  • Analogies to scriptio continua, boustrophedon, and Japanese writing are used to argue that visible word boundaries significantly aid comprehension.
  • Some fantasize about fonts/IDEs that visually enhance camelCase (e.g., anti-ligatures, overlays) or even about sharing code as ASTs so everyone “renders” with their own style.