formatting-woes.js

// 1
var obj = new C()
  .chainedMethod1()
  .chainedMethod2()

// 2
var obj = new C({
  opt: true
})

// but 3
var obj = new C({
    opt: true
  })
  .chainedMethod1()
  .chainedMethod2()

This is how I would intuitively format each example, but it's clearly inconsistent. Opinions?

3 hurts my brain, but only a little.

Why not this?

var obj = new C({ opt: true })
obj.chainedMethod1()
obj.chainedMethod2()

Chaining is overrated.

@joliss other than preferring trailing dots to leading dots I would format things the same way you do. I disagree that it's inconsistent: 2 and 3 are different cases and the indentation helps convey that.

Sorry, forgot to add my usual diatribe in the last comment. It is this: style doesn't matter. Format your code however makes sense to you and don't quibble over it too much. Occasionally, format it completely differently, just to remind yourself that it doesn't matter, and to practice not-quibbling over it.

Code formatting is the correct-arrangement-of-silverware of our industry. Who cares what fork you use, as long as the meal is delicious? There are bigger things to care about. Aim for easy detachment.

@izs Hurts mine too, a little.

The chaining is avoidable sometimes, but in some places it appears as a nested expression in a bigger call, like here. With multi-line chaining I can avoid a whole bunch of intermediate variables, and it reads cleaner.

Thanks @hjdivad.

@izs That's wise... :)

@isaacs I think there's some value in formatting things similarly between projects, in much the same way that there's value in laying out the directory structure of projects similarly. It may not be removing much friction, but it is removing some.

The value there is in picking what other people are picking rather than any particular choice being better. Having a standard code formatter that the community adopted would be a small win, just to save people from making mostly unnecessary choices.

@joliss I like chaining as well, although there are two points to be made in favour of intermediate variables:

1. You get to name the intermediate variables, which gives you an opportunity to convey intent and
2. It's often easier to debug with intermediate variables because you can quickly step over all of them and see the values of the various subexpressions. With chaining you either step slowly or write watch expressions, both of which are slower to do.

I always avoid chains because I hate having to reformat code to debug it.

var obj = new C()
  .chainedMethod1()
  .chainedMethod2()
// wait, what is happening at chainedMethod1?

var obj = new C()
obj.chainedMethod1()
debugger;
obj.chainedMethod2()

Also, stepping into the second item in a chain is difficult, but super easy if you don't chain.