The best part of this guide is that they included a eslint and jslint rules file.<p><a href="https://github.com/airbnb/javascript/tree/master/linters" rel="nofollow">https://github.com/airbnb/javascript/tree/master/linters</a><p>My team adopted this style guide and was easily able to add it as a eslint step to our existing gulp files and run it automatically. This let us use the guide without making everyone memorize the syntax differences between their personal style first.
Regarding using single quotes for strings (<a href="https://github.com/airbnb/javascript#6.1" rel="nofollow">https://github.com/airbnb/javascript#6.1</a>), I found it interesting that it's one of the rare sections where there's no rationale offered.<p>I guess it's just a stylistic choice in the end, but when we set up our own internal/informal style guide, my teammate and I spent a little while trying to come up with a justification for single vs double quotes. We ended up choosing double quotes based on the fact that JSON already made that decision for us: it requires strings be double-quoted.<p>(Although again, it's far from an important matter, as long as you're consistent), anybody has interesting rationales to share in favor of single quotes?
The fact that `typeof` is no longer safe [1][2] is news to me - it feels like they put in air bags and removed the seat belts.<p><pre><code> [1]: https://github.com/airbnb/javascript#14.1
[2]: http://es-discourse.com/t/why-typeof-is-no-longer-safe/15</code></pre>
I didn't know you could do this!<p><pre><code> // good
const obj = {
id: 5,
name: 'San Francisco',
[getKey('enabled')]: true,
};</code></pre>
Looks like a lot of good stuff but it's incredibly verbose and dense. It's important to adhere to standards but I'm not entirely convinced this doesn't end up being counter-productive. But as long as it's a guide and not a 100% "you must follow every little thing" and you can change things then maybe it's not so bad.<p>Still hard to get used to so many using ES6 already. I'm still not a big fan of transpiling but some days I feel like I'm the only one.
I love these kind of style guides. But I also love to prove them wrong.<p>Unless you "use strict", it's better to put var in-front of every variable if you put them on separate lines.<p><pre><code> var foo = 1,
bar = 2
baz = 3
</code></pre>
vs<p><pre><code> var foo = 1;
var bar = 2;
var baz = 3;
</code></pre>
Forgetting a comma or semicolon in the first example might lead to silent bugs that will take hours to find.
You can use the airbnb preset with JSCS (javascript code style checker) [1].<p>Also there's an autofix feature for most of the whitespace rules (`jscs src --preset=airbnb --fix`) so you won't have to fix everything manually.<p>[1]: <a href="http://jscs.info/overview.html" rel="nofollow">http://jscs.info/overview.html</a>
About referencing "this": It can be very useful when writing object constructors, if you always reference an object with the constructor's name.<p><pre><code> function Foo() {
var foo = this;
foo.bar = 1;
foo.az = 2;
}
var foo = new Foo();
foo.bar = foo.bar + 5;
</code></pre>
Then it will be super easy to rename say foo.bar to something else. It's also self "documented".
There is also a link on the page to browser compat style guide of es5
<a href="https://github.com/airbnb/javascript/tree/master/es5" rel="nofollow">https://github.com/airbnb/javascript/tree/master/es5</a>
Does anybody have experience integrating style guides in your existing code base?<p>Our old code base doesn't follow any style guide. After adding a style guide it requires us to go back and fix all our old files which is time consuming + kinda messes up with the git history.
<i>"Recommend using .jsx extension for React components, rather than .js"</i><p>I like .js over .jsx because I can require/import without explicit extension.<p><pre><code> import Foo from './Foo';
vs
import Foo from './Foo.jsx';</code></pre>
Why are they worried about working by reference on numbers?<p><pre><code> // bad
var a = 1;
var b = 2;
// good
const a = 1;
const b = 2;</code></pre>
As an alternative style guide, consider giving standard [0] a try. The hook is: "No decisions to make. No .eslintrc, .jshintrc, or .jscsrc files to manage. It just works." You don't have to configure anything, you just run it on your project and it'll tell you what to change.<p>[0] <a href="https://github.com/feross/standard" rel="nofollow">https://github.com/feross/standard</a>
<p><pre><code> 3.3 Use readable synonyms in place of reserved words.
// bad
const superman = {
class: 'alien',
};
// bad
const superman = {
klass: 'alien',
};
</code></pre>
What is unreadable about "klass"? Rails, for example, uses "klass" and it's never been hard for me (or, I suspect, anyone) to understand.
I'm curious as I haven't found a good coding style guide about object inheritance in ES5.<p>I usually write this even though it's a bit verbose:<p><pre><code> function Child() {
Parent.call(this);
}
Child.prototype = Object.create(Parent.prototype);
Child.prototype.constructor = Child;
</code></pre>
Any opinion on this or link to a good guide?
Maybe this is the IPA talking, but I don't think I ever want to work at a company with a style guide again.<p>This is no worse that others I've seen, but they all codify what some group found useful at some point in time, and then that becomes Company Policy set in stone for the rest of time.
<a href="http://stackoverflow.com/questions/21545687/javascript-vs-new-object-performance" rel="nofollow">http://stackoverflow.com/questions/21545687/javascript-vs-ne...</a><p>-explains why {} is better than new Object().
Alternatively, idiomatic.js <a href="https://github.com/rwaldron/idiomatic.js/" rel="nofollow">https://github.com/rwaldron/idiomatic.js/</a>, an older publication with more people contributing to it.
Love this guide. Adhere to it as tightly as possible for most new projects, saves a lot of mental overhead. Use the ES5 version for team frontend projects. :)
<p><pre><code> 3.5 Use object method shorthand.
</code></pre>
I disagree. With anonymous objects it breaks the syntactical uniformity of the expression. I think it is much clearer when each field is given a name(and a value) the same way.
Having seen this updated version I'm not terribly impressed at their guide for ES6. No mention of symbols (which are pretty important if you're using classes), generators are ignored almost entirely, a pretty poor explanation of modules, etc.
Airbnb's technical quality has been obviously crap for its entire existence. Why are we taking engineering cues from a glorified room rental site that is frequently buggy?
// bad
const items = new Array();<p>// good
const items = [];<p>They obviously spent a lot of time on this guide, lots of investor dollars, and it's of almost no use.
I think I'd go nuts in a codebase with their whitespace and brackets rules.<p>Sure, cramming the opening bracket onto the previous line is just ugly and something you could learn to live with. But there's a special type of rage that can only be generated by clicking on to the start of a line and having your cursor land 1-2 spaces to the left of it.<p>Why would anybody do that to their code voluntarily?
Use const for all of your references; avoid using var.
If you must mutate references, use let instead of var.<p>In my 15 years of programming javascript I've never once seen this matter.