Why I like snake_case – The Gospel According to Graybeard

Why I like snake_case

01 Jul, 2026

This is odd for a JavaScript developer, but I like snake_case.

Traditionally, JavaScript developers are most familiar with camelCase. That’s the convention. I used it for years because that’s what you do, son. You write getCurrentUser, customerId, createdAt, and go back to screaming inside.

But, maybe 2-3 years ago, I picked up snake_case from the Stripe API (I'd been a long time admirer of their APIs) and it stuck.

Stripe always had this plain, durable quality to it. customer_id. payment_method. created_at. billing_details. Nothing cute. Just names that look like they belong where they are.

That’s why (I think) I naturally gravitated towards snake_case. It reads like data. It looks natural in an API response, a database column, a config file, a log line, or a shell script. It doesn’t feel 'owned' by one language.

To me, that's significant because the nature of data is to move around a system (not to be fixed in one place). A user_id starts in the database, comes out through an API, gets logged, gets passed through a job, and ends up in some admin screen. The less translation, the better.

I don’t want user_id in the database, userId in JavaScript, UserID somewhere else, and user-id in a config file unless there’s a real reason for it.

Consistency reigns supreme here. Without it, even if you don't realize it, you're adding cognitive debt to your process. Each inconsistency has to be interrogated with "but why is this one different here." With a one-off, it's not a big deal. But as a pattern, it's arguably one of the biggest taxes you can pay, mentally speaking.

Snake case also makes files easier to search. audit_id is easy to find. report_id is easy to replace. The underscores create real, visual boundaries, so the name stands on its own instead of hiding inside a often hard to parse, camel-cased blob.

Not only that, but if you use an IDE like I do, matching all tokens in a file is a keystroke away. Find and replace is easy and far less error prone (less likely to accidentally match on a partial and mess up your code).

These sound like minor details until you’re cleaning up a codebase and trying not to break something dumb.

To me, snake_case is also easier to read. get_current_user has a steady rhythm to it. The words have room to breathe. getCurrentUser is fine, but it has those little humps your eye has to parse.

Of course, there are exceptions. If we’re talking about classes, PascalCase still makes sense. UserAccount, PaymentIntent, AuditReport. That convention communicates something useful: this is a construct, not a value sitting in a payload somewhere.

To be clear, this isn’t a moral argument. A consistent camelCase codebase is better than a mixed-style mess. Like I hinted above, consistency matters more than taste here.

But personally, when I’m choosing names for variables, functions, files, fields, and data moving through a system, I usually choose snake_case unless there's some unavoidable constraint (e.g., needing an API from a dependency that internally prefers another casing style).

It’s boring. It’s searchable. It travels well. Most importantly: it doesn't make my brain feel like it's solving a billion little micro-puzzles every day.

It just is, man.