On Coding Style

It’s hard to write good code. It’s easy to find yourself putting in temporary fix after temporary fix, duct taping all the holes in your website until the function nesting has more layers than a Hungarian sponge cake.

There’s an adage that goes:

Code is read more often than it is written.

This should be your one and only golden rule when writing code.

You’ll often see coding style guides in the wild. Don’t follow these. At least, not strictly. They’re a good guideline, but blindly adhering to them demonstrates a lack of critical thinking rather than an appreciation for the origin of and necessity for a style guide in the first place. Style is supposed to make your code more readable.

Most of those style guides come from companies with hundreds of employees writing thousands of lines of code. It makes much more sense for them to strictly standardize their code – it makes Git diffs cleaner, and makes it easier when reading code to switch from component to component. But if you’re writing code for yourself on your personal website, write code that YOU want to read.

For instance, take this example from the Airbnb Javascript style guide:

// bad
function foo() {
  // ...
}

// good
const foo = function bar() {
  // ...
};

This standard makes a lot of sense. The first example can cause readability issues by hoisting.

However, the second example is verbose and annoying. If i’m writing a 100-line demo on Codepen, there’s no point in bothering with that verbose syntax – and, in fact, it can make my code less readable if I need to start nesting functions. If I’m writing a small code block, I’ll just use the ‘bad’ traditional syntax and make sure to put the declaration of my function before the first time I use it.

Note that I’m not disparaging on style guides. In fact, I encourage every developer to read the style guide of every language they learn once they reach a mature enough level to understand it. Just don’t take the style guide as religion; understand it and synthesize it into your own.

Keep this in mind when you write code. Write code that is fast to read, not code that is fast to write. Unless you’re working with a large team, stick to your own standards. Just don’t be unreasonable about it.

Leave a Reply

Your email address will not be published. Required fields are marked *