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._
