snake_case

What snake_case is and why it's called that

snake_case writes identifiers in all lowercase with words separated by underscores. The name was reportedly coined by Gavin Kistner around 2004 in a forum post — a tongue-in-cheek pairing with the older "camelCase" — and stuck immediately. The convention itself is much older. C used snake_case throughout its standard library (strncpy, getenv, printf) since the language's earliest days; Unix system calls followed the same pattern.

The visual logic is straightforward. The underscore creates an unambiguous word boundary that survives case-folding, transliteration, and copy-paste between editors with different fonts. Compare get_user_by_id with getuserbyid — the underscores make the structure instantly readable.

Where snake_case is canonical

• Python: PEP 8 mandates snake_case for variables, functions, and module names. Class names use PascalCase, but everything else is snake_case. This consistency is one of Python's defining stylistic choices.
• Ruby: follows Python's convention. Methods, variables, and symbols use snake_case; classes and modules use PascalCase.
• Rust: snake_case for variables, functions, methods, and modules; PascalCase for types, traits, and enum variants. The Rust compiler will warn (but not error) on misnamed identifiers.
• PHP: historically used snake_case for functions (the entire PHP standard library uses it), though modern PHP frameworks like Laravel and Symfony increasingly use camelCase for methods.
• SQL column names: snake_case is the de facto standard because SQL is traditionally case-insensitive and case-folds identifiers, so userName becomes username in many databases — destroying the camelCase distinction. snake_case survives the fold.
• YAML keys: Kubernetes manifests, Ansible playbooks, GitHub Actions workflows — all use snake_case (or sometimes kebab-case) for keys.
• JSON in some ecosystems: APIs originating in Python or Ruby codebases often use snake_case JSON keys.

The tokenization problem

Converting to snake_case is harder than it looks. The simplest implementation — replace spaces and hyphens with underscores, lowercase everything — fails on anything more complex than three lowercase words.

Consider HTMLHttpRequest. A naive converter produces h_t_m_l_http_request (inserting an underscore before every uppercase letter). The correct output is html_http_request — the consecutive uppercase letters of "HTML" are a single semantic token.

Or consider parseXMLDocument. A naive converter produces parse_x_m_l_document. The correct output is parse_xml_document — recognizing "XML" as one token, not three.

Our engine handles these cases by tokenizing based on case transitions and acronym detection. An ALLCAPS run followed by a lowercase letter is a single token (the acronym) plus the start of the next word. A lowercase-to-uppercase transition is a word boundary. Numbers attach to the preceding token unless explicitly separated.

snake_case versus SCREAMING_SNAKE_CASE

SCREAMING_SNAKE_CASE — also called CONSTANT_CASE — uses the same separator (underscore) but uppercases every letter. Both conventions exist for different purposes within the same codebase: snake_case for variables and functions, CONSTANT_CASE for compile-time constants and environment variables. The contrast is intentional and useful — readers instantly know whether they're looking at a value that can change.

When snake_case is the wrong choice

snake_case is verbose. Eight characters for "user_id" versus six for "userId" is meaningful when identifiers appear hundreds of times in a file. In contexts where every character costs — URL parameters, minified JavaScript, command-line flags — kebab-case or camelCase produces shorter output.

snake_case is also poorly suited to identifiers that already contain underscores semantically. __init__ in Python is recognizable as a dunder method specifically because the surrounding underscores aren't separators — they're meta-syntax. If your domain has natural underscores, they'll collide with snake_case word separators.

For DOM IDs, CSS classes, and URL paths, kebab-case is conventional because hyphens are allowed in HTML/CSS contexts where underscores aren't (or vice versa, depending on the spec version). For environment variables, CONSTANT_CASE is the convention. For language-specific code, follow the language's standard — Python and Ruby developers expect snake_case; JavaScript and Swift developers expect camelCase.