Airbnb JavaScript Style Guide (github.com)

This has always been one characteristic of open source standpoints that I'm not such a big fan of. It's too tightly coupled to expect everyone with constructive criticism to also contribute. Yes, it would be good if they did. But it would strike a serious blow to many projects' mental capital if the only feedback they took from users was from those users capable (either technically or in possession of enough free time) of contributing the changes themselves.

Well, style guides are fairly subjective projects compared to most other open source projects, so while it might be worth my while suggesting things, it's not likely airbnb is going to change their style guide because I think differently to them.

Edit: Looking at some issues in the style guide repo, AirBnB seems reluctant to add or change the style guide to deviate from what they do internally (for instance, generators are rarely used, therefore they aren't encouraged).

Dynamic property names are quite different to Symbols in ECMAScript 6.

> Assuming I'm not misunderstanding your question

Numbers are not passed by reference.

It's a lazy example, that has the potential to confuse. I would agree with the downvoters I'm being petty, but c'mon... it's the very first thing you read in your JavaScript guide & it's flawed.

The purpose of the code wasn't to illustrate how to use const.

It was to show how they want you to always use const with complex types.

'const' is misleading, it doesn't set your variables as immutable. Fine for expression, but not for actual practicality.

No, no, no, this has to go away. The insertion of spaces before ) and after ( is something I see from time to time in JS code, and it is really difficult for me to read. Three.js unfortunately uses this, and mrdoob even has his own style guide. His style guide is probably the only thing I don't like about his work.

No school I've studied or worked at teaches this style, and JS traditionally has never been written like this[1][2]. And now I see it elsewhere as well. In some Java projects, for example. Where does this come from?

There are currently no known hard facts (conclusions from studies) about which of the whitespace styles have the best readability. So let's just all stick to the most common way of doing things, shall we :)

  [1] JavaScript The Good Parts
  [2] Google JS Style Guide http://google.github.io/styleguide/javascriptguide.xml

`let` doesn't disappear `undefined` though.

    >> let a;
    >> a;
    undefined

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.

Yeah, I'm not sold on "fewer characters" as a win. 'cause then we can have the code golf arguments that inevitably get into the nutty realm.

For visual parsing, consistency matters. In an object literal dec I expect:

  name : value

That's easy to parse visually. Not good is when suddenly we get:

  nameandvalue(){

in the space that our brain expects the former.

Give it time...

It looks like airbnb does a good job updating theirs, but I can sympathize with the parent comment. I've found coding style guides that end up obtuse, easily outdated, and arbitrarily fit to the preferences of it's creators. They often stagnate and are blindly followed just for the sake of following. A lot of the best practices in the document are things that should be screened for at the hiring stage, and many of the others are heavily debatable preferences that are only going to make a developer with an opposing opinion feel needlessly boxed.

Not that they are a bad thing and airbnb's looks really solid to me, but writing a coding style guide means you now need to maintain and curate it periodically – a process that is easy to neglect.

It makes sense to me that each team decides their coding standard.

5 or 20 engineers who work in the same code base should have some more or less formal standards for that code.

There's a middle ground though.

On my team, the long-standing rule is that you need to make a best effort to stick to the module's existing style. So we're not gonna bust your balls because you don't split at exactly 100 characters or whatever... but if you never wrap your lines and if you insist on indenting things completely differently than everyone else then yeah, you're creating a problem.

It also helps that our "style guide" is pretty minimal. Brace conventions, indentation, spaces before conditions, etc. Things that have a serious impact on readability and ease of debugging and that can easily be auto-formatted. What we don't specify is the higher order stuff -- provided you are internally consistent. We don't mind if API A uses one naming scheme and API B uses another, provided that we don't have a mix of different ones in the same API. Same for how something like object extension is handled. This falls into the realm of "we assume our developers will make the best technical choice", but so far it works.

There's always a complaint that specifying the braces, spacing, etc. is stupid, and if it required a lot of human intervention or was treated as a serious offense I'd agree. For us it doesn't, and it's not. The purpose is to limit the amount of visual friction when switching from one file to another. What the code is doing is the important part -- presentation should be as uniform as possible to limit distraction. Add in the fact that we've got an Eclipse profile with all the spacing, etc. setup the way that we do it, and it's pretty easy to keep things tidy.

Genuine question: Do people still adhere to 80 character limits for lines? I expected that everyone would have relaxed those with all the extra resolution we have. I use 100 at work.

Every sane linter has //NOLINT support.

I didn't even know there were "hoisting" rules - I put all my variables on one var line at the top of the file, then assign them later. Well, except for lately, function variables in JSDoc work better when the function-var is immediately assigned :-(

The style guide doesn't actually use block scope for if/loop.

Many items in the guide are...reasonable, but the explanations are gibberish or don't match the code.

the same way you would in es5?

  > new Array('a')
  ["a"]
  > new Array(2, 3)
  [2, 3]
  > new Array(2)
  [undefined, undefined]
  > new Array(2.3)
  RangeError: invalid array length
  > new Array(2.3, 4.5)
  [2.3, 4.5]

The Array constructor is really bogus. It switches to a different mode if a single number is passed.

ES6 added `Array.of` for this reason:

  > Array.of()
  []
  > Array.of(1)
  [1]
  > Array.of(1, 2)
  [1, 2]

I don't really think it's needed though. Spread and rest already take care of the common use cases.

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.

Coffeescript as well. I try to use single quotes whenever possible, so if a string is templated it stands out a bit with the double quotes.

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.

    '{ "foo": "bar" }'

    JSON.stringify({ foo: "bar" })

Do you do that more or less frequently than writing strings with apostrophes?

I'd find it very worrying that you have JSON-formatted strings in JS code. Why would you do that, when there's also a native representation?

> Typing single quotes is one keystroke

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.

You can use template strings in ES6 and avoid that whole problem.

Well, one simple typographical way to solve this is not to use a quotation character (') when what is meant is an apostrophe character (’).

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'

    'He said hello.'
    'He said "hello".'
    "Don't say hello."
    `Don't say "Hello".`
    /some regex\sstuff/

You could use ` backticks instead and use both " and ' in strings without worry

CoffeeScript follows a more common style: double-quoted strings for interpolated values and single-quoted strings are literal.

In ES6, that's no longer a problem since most HTML elements will involve interpolation with template strings and backticks.

    `<a href="${ site.url }">${ site.name }</a>`

    "<a href='www.google.com'>Google</a>"

Will work as well though.

AFAIK, return statements are literally the only place where brace style is affected by ASI.

    var result =
    {
        key: "value"
    };

    return result;

works fine, plus it lets you more easily break on the return statement and verify/modify what will be returned when debugging. It would be kind of awkward to see braces like that in JavaScript, but a style guide could just ban returning object literals and make the ASI issue moot (at least regarding braces; you still have the other gotchas with forgetting a comma in a variable declaration, etc).