Disallow newlines after dots in member expressions

[dbrockman]

Change configuration of the dot-location rule.

With this rule change the following will be disallowed:

things.
    filter(fn).
    sort();

and this will be allowed:

things
    .filter(fn)
    .sort();

things.filter(fn).sort();

[sommestad]

I think this makes it slightly less readable.

[sommestad]

However, I maintain my main principle that everyone else's already fought these battles too much... To me, it doesn't matter too much and feels like a bad time investment to debate various aspects of linting rules if someone else's already done the job. I'm sure there's plenty of s at Google who've dedicated their lives to come up with their JS style guide. I say we follow them in any cases (at least where it isn't entirely obvious).

So:

Always put the operator on the preceding line. Otherwise, line breaks and indentation follow the same rules as in other Google style guides. This operator placement was initially agreed upon out of concerns about automatic semicolon insertion. In fact, semicolon insertion cannot happen before a binary operator, but new code should stick to this style for consistency.

var x = foo.bar().
    doSomething().
    doSomethingElse();

[dbrockman]

The only thing I think is important is consistency. It is easy to get used to either style.

I don't think the google style guide is a good argument since we don't follow it that closely. They agreed upon operator placement out of concerns about automatic semicolon insertion. But semicolon insertion cannot happen before a binary operator. It is perfectly safe to have the operator after the line break.

But I really don't mind if we close this PR without merging.

[sommestad]

My only argument to follow someone else is that these discussions are like opening Pandora's Box... 🎁

We could just as easily follow someone other than Google, but they're the biggest player I've found to have an official style guide.

One other way of seeing it is to follow their guidelines instead (that's what we did from the beginning, at least).

[sommestad]

(I'm fine with either way regarding the dots, but I'm afraid this is just the start of a long journey of code style discussions... )