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()

@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.