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 (https://github.com/airbnb/javascript#6.1), I found it interesting that it's one of the rare sections where there's no rationale offered.
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.
(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?
> We ended up choosing double quotes based on the fact that JSON already made that decision for us: it requires strings be double-quoted.
My personal style guide is to copy Erlang: double quotes for text, single quotes for programmatic strings (atoms/symbols). The single quote is slightly more convenient to type on a qwerty keyboard, but text regularly contains single quotes (apostrophes). It also provides a semantic visual shortcut.
We enforce double quotes for html attributes, mainly because we enforce single quotes for PHP so when you're writing mixed HTML/PHP in the view scripts we don't need to escape any of them. Single quotes for javascript would allow for the same, though we also have a strict no inline javascript policy as well.
Mainly our rationale is, pick one and be consistent. Single quotes where there first so they win, same deal with indentation amount.
If you use contractions like don\'t inside of a string then you need to escape the apostrophe if you\'re using single quotes, which is annoying and can make the string a bit harder for humans to parse. I like the aesthetics of double-quotes better too, though that\'s not a compelling reason.
For such cases I find the Python style most appropriate. It says that you use some consistent default (e.g. always single quote), but for all a strings that require escaping, you should use the delimiter with the least (preferably no) escaping.
Note that this is easier in Python than JavaScript because Python provides more string delimiters:
'He said hello.'
'He said "hello".'
"Don't say hello.'
'''Don't say "hello".'''
r'Some regex\sstuff'
My rationale for single quotes is also that JSON chose for you -- if you have JSON-formatted strings in your javascript and you use single quotes for your strings, you don't have to escape the double quotes.
Also, C uses double quotes (and JSON, and many, many more languages). That used to be my rationale. These days I get away with saying that 'foo' and `foo` look too similar.
I use double quotes for most strings and single quotes for characters, just because it's perfectly valid without having to learn new habits.
If I have HTML in a JavaScript string, I don't quote the attributes at all unless necessary, instead focusing on more pressing matters like how to get that shit out of my JavaScript.
Single quotes are less busy. Strings are all over my angular app usually, so having half the number of little lines flying around is much more pleasing to my eyes.
we use double quotes for HTML and single quotes for JS. that makes it easy to embed HTML snippets in Js code and JS snippets in HTML attribute values without escaping.
Single quotes are a big big pain if you have strings with apostrophes (which is common in names: O'Brian, d'Alembert).
You can escape them, but that's an extra pain and strain on readability; you can use some other character but that will usually cause problems down the road.
Why so many people insist on single quotes is a mystery...
The rationale I have for using single quotes over double quotes in javascript is that when embedding HTML elements, attributes are often quoted in double quotes.
If JSON requires the string to be double-quoted, then it's more convenient to use singe quotes, since your embedded JSON string (if you ever used it) won't need to have its quotes escaped.
Interesting. Is that common in your workflow to embed JSON as string literals in JavaScript? Never had to do that. I'd probably use ES6 backticks, so as to have multiline support and skip the need to escape both single and double quotes.
JavaScript up to ES5 doesn't support string interpolation at all. ES6 introduces backticks `before${var}after` for that, but there's still no functional difference between single and double quotes.
The only code affected by this would be code that uses typeof to check for the existence of a variable the same code defines later, which sounds like dumb code to begin with. I don't think there's any valid uses of typeof on possibly undefined variables besides checking for browser built-ins.
Using typeof(foo) === "undefined" is actually something that comes from back when it was pretty common to pollute the global namespace. There were actual javascript plugins/libraries/snippets that defined undefined and thus broke code that compared to it.
That's... interesting. I guess it makes a little sense -- `let` seems to be for developers who don't like `var` semantics. Usually that seems to be about wanting block instead of function scope, but maybe there's a contingent that dislikes `undefined` too.
Next to arrow functions and optional arguments, better object syntax is one of the big reasons you should be using Babel today. You know how sometimes you need to precalculate values that are going to be returned in an object, so at the end of the function, you return something like this?
return {
foo: foo,
bar: bar,
baz: baz
};
You don't have to do that in ES6.
return {foo, bar, baz};
Keys without values use variables with the same name as their values.
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.
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.
Yes, there is a mix of pragmatic advice (with citations) along with stylistic opinions. I think the ES5 version is also quite good. Look at the number of forks, though. I might use this as the basis for a style guide for my organization. I think I'll probably fork it, though, and remove the opinionated bits. I did enjoy the writing style.
If you add a lint checker, like jshint, to your build steps those kinds of bugs are found instantly. You can also add these specific style guide checks to your build steps using jscs (https://www.npmjs.com/package/jscs).
Readit News
https://github.com/airbnb/javascript/tree/master/linters
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.
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.
(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?
My personal style guide is to copy Erlang: double quotes for text, single quotes for programmatic strings (atoms/symbols). The single quote is slightly more convenient to type on a qwerty keyboard, but text regularly contains single quotes (apostrophes). It also provides a semantic visual shortcut.
Mainly our rationale is, pick one and be consistent. Single quotes where there first so they win, same deal with indentation amount.
Note that this is easier in Python than JavaScript because Python provides more string delimiters:
Not on my keyboard.
Also, C uses double quotes (and JSON, and many, many more languages). That used to be my rationale. These days I get away with saying that 'foo' and `foo` look too similar.
If I have HTML in a JavaScript string, I don't quote the attributes at all unless necessary, instead focusing on more pressing matters like how to get that shit out of my JavaScript.
You can escape them, but that's an extra pain and strain on readability; you can use some other character but that will usually cause problems down the road.
Why so many people insist on single quotes is a mystery...
So it's much nicer to write
than to constantly escape argument strings.https://github.com/airbnb/javascript/tree/master/react#quote...
Deleted Comment
Your editor should immediately highlight this error with a squiggly line.
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.
Unless you "use strict", it's better to put var in-front of every variable if you put them on separate lines.
vs Forgetting a comma or semicolon in the first example might lead to silent bugs that will take hours to find.https://github.com/airbnb/javascript#13.2
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.
[1]: http://jscs.info/overview.html