Google releases a variety of guides for web designers and developers. These include recommendations for working with styles, icons, code implementation, and more. They haven't overlooked JavaScript either, for which they decided to create their own guide (and what better time than now) to show what they consider clean, proper, and ideal code. The guide is quite extensive and thorough, and many developers will find it worthwhile to review.

In this article, we’ll focus on some specific aspects of the guide and explore them in more detail. Our readers may recall that we previously published a similar piece regarding proper practices when using Photoshop in web design ( etiquette ). And now, something similar awaits you — but this time about JavaScript.

We'll look at everyday aspects of code: tabs, semicolons, alignment types, different functions, long lines, and much more. Of course, all the details and even more interesting content can be found in the official Google guide .

Various Styling Conventions

Surprisingly, styling isn't just for visual elements — it applies to code too. Every developer has their own style, the one they write in when they’re not thinking about existing guides, based on how they learned to code, what they read, and what they’ve seen.

But when working in a team, a shared guide is always necessary. You can’t expect harmony while going solo in a group. The same applies to web development, design, or any other team-based activity. The real issue lies in the nuances of each available style guide.

If you compare Airbnb, MDN, Google, jQuery JS Style, and others, you'll notice they differ in the details but share many core ideas. Is it really that important to learn every tiny rule in each guide? The answer is twofold. On one hand, a computer or browser doesn’t care how the code is formatted — as long as extra spaces or slashes don’t cause errors. But if the code will be edited later — potentially not by the original author — then style and clarity, cleanliness and readability , become very important.

Google started working on their guide a long time ago, back in 2010. And only in 2018 did they finally finish and polish it. It differs from other guides in some ways but also shares many similarities. It’s unique and continues to spark plenty of discussions and debates — and that’s a great thing!

So let’s dive into what Google recommends for writing JavaScript code, and compare it to other popular guides.

Semicolons

Every statement on its own line must end with a semicolon “;”. These should be inserted manually, not left to automatic line-ending features that some editors provide for convenience.

Yes, there are still developers who refuse to use semicolons, claiming they simply prefer it that way , or citing the standardjs.com guide. But in Google’s opinion, clean code is understandable code. So the semicolon is required and mandatory.

Horizontal Alignment Is Not a Priority

Google takes a neutral stance on horizontal alignment. It’s neither encouraged nor considered necessary. If it has already been used, there’s no need to repeat it.

In other words, Google doesn’t require developers to manually add spaces at the beginning of a line so that tokens align perfectly across multiple lines.

In fact, they take a somewhat negative stance on unnecessary spaces. So next, let’s talk about spacing.

Forget the Tab

The only acceptable space character in the entire codebase should be the regular space, not Tab. In ASCII, that’s (0x20). So tab characters should never be used for indentation.

Google also states that indentation should consist of two spaces — not four, as some other guides recommend. So every new block should start with just two spaces and close accordingly.

Let’s mark spaces with a “+” to show how clean JS code might look:

Forget "var"

Variables should be declared using let or const . The latter is generally used by default, and the former is used when reassignment is necessary. But var should not appear in the code at all.

Surprisingly, if you check StackOverflow, you’ll still see code examples using var . But that’s up to the developer and the nature of the platform. Although there are many discussions about whether we should really forget var . Either way, there’s no strict rule, and habits may persist — but it’s worth trying to follow modern guidelines.

Arrow Functions Are Important

Arrow functions simplify code, resolve complexity, and make the syntax cleaner. So when working with nested functions, it's better to use arrow functions instead of keywords.

And honestly, they look nice, are compact, and get a lot done. It’s great that Google supports them!

Most of what we’ve discussed so far also applies to the well-known guide from Airbnb . They share many similarities, but if they were exactly the same, there wouldn’t be a need for both guides. Let’s now look at some key differences.

Line Continuation and Long Lines

Google advises against using line continuation characters (like a backslash) for long lines. Yes, ES5 allows it, but Google believes it may lead to bugs — especially if there’s a space after the slash.

As for Airbnb, in section 6.2 , they recommend leaving strings as they are and not doing anything special.

How should developers approach this? It’s a personal decision. No one says you must follow just "this" or "that" guide. The choice is yours.

Forget "eval"

Google strongly supports recommendations from Mozilla’s MDN . Both guides agree that neither the Function(…string) constructor nor eval should be used for code loaders. These functions don’t work in CSP environments anyway.

MDN clearly and loudly states that eval is a dangerous function — it executes code with full privileges. There are safer and faster alternatives for almost any common use case.

Google also touches on ES6. But here things get complicated. On one hand, they advise against using some specifications, while on the other, they outline limitations in different areas. So...

"for" Loops vs. "for…of"

ES6 includes three loop types. All are valid, but Google prefers the "for…of" loop.

It’s a strange choice — developers traditionally chose loops based on the task. For example, "for…in" worked well for objects, while arrays were processed using "for…of".

Still, Google chose to favor just one .

ES6 Modules

Again, we see differences between Google and Airbnb. Google cautions against using modules (import/export), citing unfinished semantics and a lack of full standardization. Airbnb, on the other hand, encourages their use.

Conclusion

Any style guide in web design or development isn’t a strict rulebook. It’s a set of recommendations. The difference lies in who wrote it. If it came from someone obscure, people might ignore it. But when it’s written by a giant like Google, it naturally draws attention.

Considering they also published guides on C++, HTML/CSS, AngularJS, Vimscript, and more, it’s clear these are people who spend a lot of time writing and maintaining code — and know what works best for long-term usability.

But nothing stops you from combining different guides — picking methods from one and advice from another. This way, you can create your own style that works best for you or your team. Often, that’s even better than rigidly sticking to a single standard. But that takes a lot of real practice.

When comparing the two best-known guides (Airbnb and Google), many developers find Airbnb’s guide more user-friendly and warm than Google's. But in the end, it’s all a matter of personal experience and choice. Just remember: if you adopt certain recommendations, keep them consistent. If you choose spaces over tabs — use spaces everywhere. If you avoid slashes — avoid them throughout the whole project.