CamelCase vs underscores: Scientific showdown (2011)

Original Article ↗ Hacker News Discussion ↗

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.