Hacker News new | past | comments | ask | show | jobs | submit login

While looking through the slides, I was wondering:

Is there some community-standard way of naming/declaring a JS function to let the programmer know just by reading the function's name that it will return a promise instead of a final computed value? I'm interested in knowing how people handle this. It's easy to forget that a function doesn't return a promise if the function name makes no mention of it, so I just make it explicit in the function name... but that's just how I handle it.

I'm getting in the habit of letting the caller decide, something like the following:

    myAsyncFunc = function (param1, param2, callback) {
      var usingPromises = (callback === undefined);
      var returnVal = usingPromises ? Q.defer() : this;

      someFunction(function (err, res) {
        if (usingPromises) {
          err ? returnVal.reject(err) : returnVal.resolve(res);
        } else {
          callback(err, res);

      return returnVal;
So if I call myAsyncFunc(foo, bar) it returns a promise and if I call myAsyncFunc(foo, bar, cb) it returns itself for chaining.

Functions should be documented with the types of their parameters and return value.

I suppose I've just learned to really appreciate the "?" and "!" at the end of ruby function names...

If that function is "supposed" to be async and its last argument is not something looking like "callback", there's a great chance it's a Promise.

Otherwise, there's no "naming scheme" for promise-based functions.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact