2

I am making some modules in Node.js and wondered: "Is there a convention for when to use return statements in Node.js?".

From what I understand return statements should be avoided since they would make the process a blocking operation, but is there a guideline to when they should be used, and when one should stick to callbacks?

user123444555621
  • 148,182
  • 27
  • 114
  • 126
Eivind Eidheim Elseth
  • 2,294
  • 1
  • 23
  • 28
  • I don't understand - don't you need to use return when you need to return a value? – nnnnnn Jun 24 '12 at 19:30
  • possible duplicate of [What is the use of return statement inside a function?](http://stackoverflow.com/questions/6562679/what-is-the-use-of-return-statement-inside-a-function) – Esailija Jun 24 '12 at 19:30
  • P.S. Even without a return statement a function still returns _something_, i.e., undefined. Functions don't automatically become asynchronous when you don't have an explicit return. – nnnnnn Jun 24 '12 at 19:39
  • Sorry, I should have clarified that I meant as to opposed to when one should stick to callbacks. – Eivind Eidheim Elseth Jun 24 '12 at 19:42
  • I edited the question title, so it can be better understood in the overwiew – user123444555621 Jun 25 '12 at 07:13

2 Answers2

2

Whether something is "Blocking" or not is up to you -- does it take much time?

Any IO operation should be considered blocking, as it relies on something outside the script (which could take any amount of time).

If your own script were to say, loop over something a couple hundred times (And you know this to take more than a fraction of a second) you might consider it blocking.

  • If a method is blocking, it should accept a 'callback' parameter, and call that asynchronously.
  • If a method is non-blocking, it should not accept a 'callback' paramater, and should have at least one 'return' statement.

Your convention should simply be that you know a function is asynchronous because it accepts a callback.

Dean Rather
  • 31,756
  • 15
  • 66
  • 72
  • Note that an asynchronous function (who accepts a callback parameter) may also have a return, which would return itself; good for 'chaining' – Dean Rather Jun 25 '12 at 07:11
  • I actually only came to those realisations about the conventions etc. over the last 2 months while learning Node.js myself :) – Dean Rather Jun 25 '12 at 15:43
  • Why blocking code should and non blocking shouldn't accept callback? Isn't it the other way round? Is that a typo in the bulleted points – Tamil Jun 25 '12 at 15:52
  • No that's the way it should work. If a function is non-blocking, you can use it like any regular function -- that is, wait for it to 'return' from it's processing. If a function is blocking you want to proceed with serving other things, and have it perform the callback once it's done. – Dean Rather Jun 25 '12 at 23:41
0

If it's a "cheap" operation, that's perfectly fine. Any operations which are performed multiple times where you're not doing CPU-intensive operations can (and often should) be refactored into a "normal" function. This is fine:

function add(x, y) { return x + y; }

This is not:

function fib(n) {
    if (n <= 1) return 1;
    // this may take a long time if n is large
    return fib(n - 1) + fib (n - 2);
}

A possible implementation of fib would take a function to return the result as a parameter, and spread the calculation over multiple calls. Something like the code below, from the book "Node Web Development":

function fib(n, done) {
    if (n <= 1) {
        done(1);
    } else {
        process.nextTick(function() {
            fib(n - 1, function(val1) {
                process.nextTick(function() {
                    fib(n - 2, function(val2) {
                        done(val1 + val2);
                    });
                });
            });
        });
    }
}

Where the thread wouldn't be blocked for long.

Yes, a better alternative would be to implement fibonacci in the iterative way, not the recursive one. But this is just to demonstrate how one could "split" a CPU-heavy function.

carlosfigueira
  • 85,035
  • 14
  • 131
  • 171