关于回调的Coffescript和Node.js编码风格

Question

Let's get to the point. I love CS, I love node and I'm more than fine using callbacks as the Gods have suggested.

Unfortunately I usually end up constantly checking for errors in slightly nested callbacks.

Below are three different styles to accomplish the same sample task. Which would be the one to use to avoid indentation and condition hell and at the same time not sacrifice on readability?

Please feel free to suggest a new one if not using promises, async or iced-cs.

authenticate: (token, cb) =>
  @collection 'services', (err, collection) =>
    if err
      cb err, undefined
    else
      collection.findOne token: token, (errFindingService, service) =>
        if err
          cb errFindingService, undefined
        else
          cb undefined, service

authenticate: (token, cb) =>
  @collection 'services', (err, collection) =>
    if not err
      collection.findOne token: token, (errFindingService, service) =>
        if not errFindingService
          cb undefined, service
        else
          cb errFindingService, undefined
    else
      cb err, undefined

authenticate: (token, cb) =>
  @collection 'services', (err, collection) =>
    return cb err, undefined if err
    collection.findOne token: token, (errFindingService, service) =>
      return cb errFindingService, undefined if err
      cb undefined, service

PS: On the second one I'm using if not err instead of unless to conform with https://github.com/polarmobile/coffeescript-style-guide

Thank you all in advance. ^_^

Answer 1

My preferred boilerplate for error handling in CoffeeScript is return callback error if error . So

queryDb conditions, (error, results) ->
  return callback error if error
  console.log result for result in results

• it's a 1-liner
• I strongly prefer error handling to always be at the top and to short-circuit the logic with return
• this leaves the success code at the same indentation level, as opposed to do an if/else

Answer 2

The first one is closer to what nodejs uses internally, for example in the fs module.

err is the first argument, so it makes sense to check it first. Once that it out of the way, it 'drills down' deeper into the callback stack.

The first and third options compile to the same JS, except for the explicit return.

Which is easier to read and identify the essential pieces? Think about reviewing the code a couple of months from now.

Coming from a Python background, I prefer to use a more open structure (eg the first), unless a more compact form is clearer. So while I like Coffeescript comprehensions, I am less enamored with expressions that omit all possible {} and () . If I have to stop and mentally add those back in, the conciseness has gone too far.

Answer 3

Using flat-flow it can look something like this:

{ flow } = require 'flat-flow' 

authenticate: (token, done) ->
  flow { getCollection: @collection }, [

    # Get collection.
    (done) ->
      @getCollection 'services', (err, collection) ->
        done err, { collection }

    # Get service
    (done) ->
      @collection.findOne { token }, (err, service) ->
        done err, { service }

    # # Get service (alternative)
    # (done, { collection }) ->
    #   collection.findOne { token }, (err, service) ->
    #     done err, { service }

  ], (err, { service }) ->
    done err, service

    # You can use @service as well.

It's still clean on long call chains (with or without conditionals).