Why we use snake_case for variables and camelCase for functions

Alexandre Leduc — Tue, 20 Aug 2024 22:55:01 +0000

To be less stressed, and therefore better programmers, we have to do our best to free our code from bullshit that makes it a hard to maintain, and hard to onboard new devs-to.

We use the same name for database fields, JSON property names returned from an API, the HTML form field name attributes, and finally, the Javascript variable names that contain those database-originating values. Naming your data exactly the same in all layers of the stack frees you from having to keep a mental mapping of what is what. Discipline yourself to enforce this rule, and you will be a less stressed programmer.

We use snake case for naming variables we define ourselves. It sets them apart from most things that are defined in a library, because most libraries use camel case for variable names.

We use full words instead of acronyms, and if something is an array, it is spelled plural. This helps people from all nationalities understand what a piece of data is, without knowing shorthand versions of words.

We use camel case for function names simply because it allows us to quickly identify that an identifier is a function, and not a variable. Yes, I know functions can be saved as values, but the difference is that you can't call a primitive/object/array value by adding parentheses to it. That's where the line between function and value is, and having a visual cue to tell one from the other is helpful.

Opinionated code formatters suck (*)

Alexandre Leduc — Sun, 03 Dec 2023 17:19:45 +0000

(*) Unless you are OK with the formatting rules they impose on you.

This article makes the case that opinionated code formatters like Prettier and Biome, and the argument they make that providing customizable formatting rules only serves to enable bike shedding arguments between coders, is a fallacy.

Code formatting is a topic that is dear to many programmers who have spent years working on huge code bases, because they help teams maintain a consistent format and, as a result of that uniformity, can greatly help with code readability. I put the emphasis on code readability here because this is the true value that formatters provide. The easier it is for programmers to read each other's code, the faster they will be at understanding it.

The specific formatting rules that are enforced by a formatter, and whether they make code more or less readable, is a highly subjective thing. For example, whether you think that putting an 'else' on the same line as the closing curly brace instead of a new line, is more or less readable is a matter of personal preference. Perfectly valid arguments could be made for one way or the other.

if(i === 0) {
    // do something
} else {
    // do something else
}

if(i === 0) {
    // do something
}
else {
    // do something else
}

However, just because something is subjective doesn't mean that it's not valuable, or that all point of view are equal. The value of a point of view is in the eye of the beholder. If my team is used to putting an "else" on a new line, then that's the valuable formatting rule for us. It would be pointless to argue about it. If your team is used to code that is formatted a certain way and a new hire changes all the code base's formatting by installing Prettier, you will get a lot of teeth grating from the coders who are used to the in-house style and have come to expect things to be formatted a certain way. Arguing that everyone should just accept the formatting rules picked by some tool author that doesn't care about the way you do things just means that your own subjectivity aligns with that of the tool author. Good for you! Too bad for everyone else who thinks the opinionated format is less readable.

Who are the opinionated formatter's authors to decide what's best for everyone else?

Dismissing everyone's subjectivity by imposing the subjectivity of the authors of the formatter does not provide any value. Giving users the option to customize the formatting doesn't take anything away from teams that are perfectly fine with using the defaults. The reverse is not true. If Prettier/Biome were configurable, team leads could enforce internal formatting rules in its configuration files and not have to worry about rogue devs installing one of them and reformatting the whole code base.

A formatter should concern itself with enforcing the rules that fit users of that tool, not that of the authors of the tool.

A closer look into the bike shedding argument

Such debates over code formatting might be something people do on the Internet, but in real work scenarios, that's not something I have seen happen. This feels like a straw man argument to justify imposing your own subjectivity on others. On all projects I have worked on, the lead developer decided the (ESlint) formatting rules enforced on the project and that was never up for debate.

The value of a formatter is in enforcing the rules that makes the code more readable for you. Dismissing someone's else's need to use different rules as bike shedding, or an example of tragedy of the commons, is short-sighted at best, arrogant at worse. Whatever formatting rule choices these tool authors have made is what they think readable code should look like. It doesn't make the code universally more readable for everyone.

Prettier & Biome VS ESlint

Where I work, we use ESLint as a formatter because it allows us to customize the formatting rules to what we consider to be more readable, and it works perfectly fine for our needs. So you might ask: "Why don't you just keep using ESLint and let everyone else who likes opinionated formatters use that?". Well, this rant came as a result of learning about Biome, a formatter that is written in Rust. I installed it to see how much faster it is and got immediately excited about the noticeable difference compared to other formatters written in JavaScript. As a developer working on huge code bases, I often find the performance of some of the tool chain (formatters, linters, etc.) sluggish, and I'd like to adopt anything that makes my workflow faster. But as soon as I looked at the limited formatting configuration options, I immediately discarded it as yet another thing that doesn't recognize my subjectivity as valid and valuable.

I doubt it will make the authors of Prettier and Biome change their minds, but I hope that if someone decides to port ESlint to Rust in the future, they will not take the easy road of imposing one-size-fits-all formatting on us. The tooling ecosystem should provide more options, not less.

DEV Community: Alexandre Leduc

Why we use snake_case for variables and camelCase for functions

Opinionated code formatters suck (*)

Who are the opinionated formatter's authors to decide what's best for everyone else?

A closer look into the bike shedding argument

Prettier & Biome VS ESlint