Why does JavaScript need a style guide?

[ColemanGariety]

One of my favorite parts about the JavaScript community is that people choose to write it in so many different ways.

Why do you want to ruin that with a style guide?

Imagine if when Picasso was learning to paint, we told him what style he should paint in. Would we have cubism?

[hshoff]

Hi @JacksonGariety, interesting example. Hope you don't mind if I run with it for a bit.

Let's say you start an e-commerce site.

Your first engineer is Picasso during his blue period. Your codebase quickly becomes filled with Picasso blue period javascript files. He paints you a javascript shopping cart without a problem. He's done it a million times before. But this is his best one. It's his masterpiece. And very blue.

Your second engineer is Salvador Dali. He shows up on his first day with a camera, a single paintbrush, a silly mustache, and starts contributing some crazy surrealist javascript files.

This influences Picasso as they work together and Picasso starts switching things up and begins adding cubism files to the codebase. The codebase is so new that Picasso and Dali can continue adding new files at any time with no harm, because there is no maintenance when it's just two engineers adding new functionality. No one is stepping on each other's toes. There's enough paint for everyone.

Then you hire Monet and he comes in and leaves his impression on everything.

Now you have a blue period shopping cart, impressionist image lazy loading, surrealist photo slide show, and cubism style event tracking in /app/assets/javascripts. The javascripts folder becomes a museum.

Let's jump to the future 4 years later. Lots of major functionality has already been built. Picasso has left the company to pursue a company built on a guernica style. Your business focus has shifted a bit and you need someone to extend Picasso's blue period shopping cart to support collaborative shopping (lots of people sharing the same cart in realtime).

Luckily you just hired a rising star in javascript land that likes to spray paint things on the wall, his name is Banksy. So you tell Banksy, "Hey for your first job we need you to modify our shopping cart so it supports collaboration. Timing is really important for the big relaunch, fortunately this should be really easy because we already have Picasso's shopping cart and it's already a masterpiece. Just reuse that."

So Banksy goes in and spray paints over your Picasso shopping cart and makes it collaborative and you have a big successful relaunch.

A month later a bug report comes in about removing items from the shopping cart. Banksy is busy on another project, so you get Monet to go in and fix it.

Monet doesn't know how to use spray paint cans. So his attempts to fix it are sloppy. He breaks the build. He switches back to the brush and just paints over it, but it took a lot longer than it should have because of the time to understand and adopt an unfamiliar style.

When you have over 80 engineers contributing to one codebase, you quickly learn your usual ways of doing things don't work. So we try to turn everyone into Picasso. No matter where you jump in to the codebase, all the files are familiar and look like they were painted by you.

The most important thing, no matter what your preferred javascript style is, is to be consistent when working with a team or a large codebase that will have to be maintained in the future.

The style that works best for our team is our Picasso style since that's how it all started.

We open sourced our style guide so other teams could fork it and turn it into a Monet style guide or a Banksy style guide. Which is lots of fun to watch.

As an individual painter/engineer working on side projects and exploring all the wonderful things you can do with javascript, please throw conventions away and ignore everything anyone has ever said.

It's the only way the world will enjoy the next Picasso.

🍻

[ColemanGariety]

@hshoff What a great answer, thank you.

My only fear is that people will abuse a single style guide to no end and code will become generic and timeless.

[kientran]

One would argue the most important code in the world is in fact generic and timeless. E.g. College Algorithm Textbooks.

[ColemanGariety]

@kientran is that really the most important code in the world?

Or is the most important code the Linux kernel, or v8, or jQuery, or NodeJS?

Just because something is prevalent doesn't mean it's making a positive impact.

[6twenty]

@hshoff that's one of the best comments I've come across on GitHub. Nicely said!

[fmundaca]

@hshoff your example is awesome ! nice !

[jaseemabid]

@hshoff I wish I could <3/+1/fav/something that comment :)

[tmikaeld]

This is programmer poetry! So beautiful it makes you cry.. of pain.. of happiness... of sadness.. or anxiety.. when looking at your own code.

[morgante]

Any anti-coding style arguments for JavaScript apply equally well to any language. And, like for all languages (as @hshoff put so beautifully), a coding style improves readability, coordination, and maintainability.

[zeroxff]

@hshoff great answer!

[rottmann]

Think not only on your code, think about every project from others.
Every time i use components from other developers, i had to read first the style of their programming, thats annoying.

[robknight]

You need a style guide to prevent pointless changes due to differences in style preference between contributors. If I find your 8-space indenting annoying and change it to two-space indenting (which is about three keystrokes in emacs), I'm either going to commit something like "Fixed indenting" which is going to take up a line in the git log, or I'm not going to mention it at all, which means that some other commit is going to involve changing every single line of a file, effectively obscuring the purpose of the commit. Even worse, either of these commits breaks git blame for the affected file.

A style guide is like a grammar - you need shared rules so that any changes you make to other people's code are about changes in meaning rather than changes in style.

[rowanu]

@hshoff's comment is also a masterpiece!

@robknight's point about avoiding "pointless changes between contributors" is key too. Different programmers will express themselves in different ways, even while adhering exactly to the same style guide.

[jh3y]

@hshoff's response is fantastic, A+.

[gtd]

@hshoff to be fair though, if I could hire that level of talent I'd let them do what they damn well please :)