Forget About [Code] Style

Good code style, being highly subjective, is something often debated among developers. After all, we spend more time reading code than writing it, so it's worth making sure our code is styled to be as easy as possible to read and to understand. On the other hand, deciding upon and continuously enforcing a style is also time-consuming, and the benefits are near-impossible to quantify. Given that modern code formatting tools can fully automate the process, is it still worth fretting about style?

The Hidden Costs of Being Stylish

Suppose your team or your company decides that it's more readable to place opening curly braces before the newline, i.e.

if (cond) {
    ...
}

rather than after it, i.e.

if (cond)
{
    ...
}

This small rule carries with it a number of hidden costs:

1. Defining the style: It took at least a few minutes to decide on the style, more if bikeshedding takes place.
2. Configuring tools: To save developers time, tooling can be used to catch or even to automatically fix violations of this style, but it takes a little time to configure that tooling.
3. Thinking about style: Developers now need to be thinking about this style while they work. That might sound silly, but when a developer has their own differing preferences, or when they have experience using a different style (e.g. on previous teams or outside of work), each rule takes a little bit of brainpower to remember and to follow.
4. Dealing with automated style rejections: Every time a tool rejects code due to style violations, a little time is wasted. This can for the most part be avoided using IDE integrations that auto-format code on save, but still affects certain areas (like using online code editing features in source control providers like GitHub or GitLab).
5. Dealing with code review style rejections: Even worse than automated style rejections is when there is insufficient automation in place, and style errors are caught manually in code review.

These costs may seem trivial, but given that most style guides have tens or hundreds of rules, they add up. Is it worth all of that just to have curly braces in the place the developers prefer? Or, to put it another way: does it matter where the curly braces are, if tooling can enforce it one way so seamlessly that developers never need to think about it?

The Benefits of Having No Style

Many mainstream languages today have one or more so-called "opinionated code formatters", for example:

• Prettier or Standard JS for JavaScript and TypeScript
• Black for Python
• CSharpier for C#
• rustfmt for Rust
• gofmt for Go

They're called "opinionated" because they provide little to no configuration capabilities, instead deciding most things for you. If your language of choice is in the above, I encourage you to look at an example of one of those formatters' outputs. What do you think? It likely follows several rules you would choose differently, and you could likely produce nicer code than it can by judiciously breaking the rules in special cases where it's appropriate to do so. But I strongly suspect that overall, you'll find that the output looks... fine. It's readable. It works.

Now, consider that with a just a few lines of configuration, you could have your editor automatically format your code on save to fully match the style, with additional checks on git push and/or in CI in case anything slipped through.

No time spent with a committee of developers deciding on the best place for curly braces.

No time spent mentally context-switching between a work codebase that does things one way and an open-source codebase that does things another way.

No time spent in code reviews pointing out minor style violations.

Just type out a hideous-yet-functional stream of code in whatever way suits you, hit "save", watch your code instantly get prettified for you, and move on. That doesn't sound like much, but once you've experienced it, it's hard to go back. And once you get used to tolerating some rules you disagree with, you start to realize that what's more important than seeing your preferred style is seeing a consistent style, and that's something that can be fully automated.

The next time you're configuring a project, consider using an opinionated code formatter, and saving your brain power for solving the real problems.