We need to systematically add all the JS preferences.

[nelsonic]

We need to go through https://github.com/airbnb/javascript line-by-line and adopt/adapt the parts we want. any volunteers to kick this off? @dwyl/doers

[eventhough]

@nelsonic I've been using eslint-config-airbnb on both my back-end node project and my front-end react project. For front-end I only have one override:

{
    "extends": "airbnb",
    "rules": {
      "new-cap": 0
    }
}

http://eslint.org/docs/rules/new-cap.html

This is because if you use a library like Immutable.js eslint will throw an error when you create a new immutable List() or Map().

On the back-end I basically just copied all the airbnb rules but removed React/JSX stuff because my project is not universal/isomorphic.

[nelsonic]

@eventhough cool. thanks for the insight! :+1:

[MIJOTHY]

I like everything in the AirBnB guide apart from the dangly IIFE (they use (fn(){})(), but I think (fn(){}()) captures the idea better) and their section on comparison operators & equality where they recommend shortcuts, as that makes code less transparent (do you care about any falsy result, or only numeric 0 and have decided to use a shortcut?)

[nelsonic]

@MIJOTHY can you elaborate on why the "dangly" IIFE is sub optimal? (thanks for feedback! hope you're well!)

[MIJOTHY]

Yeah I'm not bad thanks, getting pretty rusty though haha. I met a student who does unity programming and we're gonna do some C together and probably some hackathons, but other than that, there's been not much programming really.

Anyway, onto my reasoning:
The only need for the surrounding brackets is so that the code is interpreted as an expression, so in that sense, the thought which the brackets are expressing is that the entirety of the fn(){}() should be interpreted in a certain way, and not that fn(){} should be interpreted in a certain way on its own. To put it another way, the brackets are a tool here that are used for forcing something to be seen as an expression. Since an IIFE is the entirety of the fn(){}(), the brackets should be placed surrounding this expression.
I think in the simplest sense, an IIFE is a package of code in itself, and so should be grouped by parentheses accordingly. From the package perspective, it makes little sense to wrap just the fn(){} in parentheses. It also seems strange to wrap a function in parentheses only in this situation.
I haven't really had any discussion on this matter though, so I'd be interested to hear other thoughts.

[rjmk]

Well, the obvious alternative thought along those lines is that an IIFE is actually two parts, it's immediately invoked, and it's a function expression. The brackets could be used solely to force a function into expression position, for example if you wanted to grab a method of a function and didn't want to go to Function.prototype. Admittedly, that would be stupid but the point stands I guess.

Having written that, I now think that the inner brackets do capture the process that's happening better than the outer brackets, but suggest going with whatever's clearer.

[nelsonic]

At the time we created: https://github.com/dwyl/goodparts based on "JavaScript The Good Parts" https://github.com/dwyl/Javascript-the-Good-Parts-notes to encourage all JS the best practices. It was used extensively in our JS projects. We have since moved on to other languages.

Closing. ✅