Style Guides & Bike-Shedding

Let’s say that you work at a nuclear facility. You’re forming plans to create a new sector for the facility. At the meeting, everyone agrees on the plans within ten minutes, as they are highly technical and various people from different backgrounds wouldn’t be able to understand what others are saying.

However, someone raises an idea of building a bike shed next to the new sector, so workers can bike to work. Then, you start discussing the size of the shed. The material. The color. Next thing you know, it’s been 45 minutes and no one can agree on whether the shed should be purple or bright green.

While this is a comical story, things like this are very prevalent in software development. Should I add spaces after a colon? How big should my tab size be? Do I add a blank line after a function declaration? These types of things can waste a lot of a team’s time. Even if you crunch every day and work 80-hour weeks, it’s no use if half your day is screaming at your tech lead about how adding curly brackets in your code makes it more maintainable (based on a true story).

The Solution: Style Guides

Style guides are exactly what they sound like: guides on how your code should be styled. Not everyone has to agree on them, but they should at least be present. Every team should, at the start, agree on certain compromises so they have a consistent code style. This allows the code to look like it’s been collaborated on and made by a team, not just patched together.

If your team really just cannot agree on whether two spaces is better than four spaces for indentation, you can turn to popular style guides. For example, AirBnB has their own style guide for JavaScript that’s pretty popular. Even better is the Google style guides, covering everything from JavaScript to Lisp.

Having a style guide that some people might not agree with is always better than having none at all. At the very least, use the built-in styles your IDE comes with.

Formatting Tools: Our Savior

However, most people don’t always code with formatting in mind. The last thing you’re focusing on at 4:00 on Friday when you’re going to hang out with the bois in an hour is that the styles your team agreed on is to always add curly brackets.

This where automated formatting tools comes in. While you may code sloppily, you can configure tools such as Prettier (my personal preference) or ESLint to format them automatically, at the press of a button (or a terminal command). In fact, some IDEs even have them directly integrated, so you can configure your IDE to format your code automatically!

There are also tools such as Restyled that allow you to automatically format your code on every pull request. Now we’ve reached peak-laziness! There’s really no excuse to not be consistently styling your code at this point, with all these tools. So really, just an npm install prettier can make your code so much more pleasing to read.