Search code examples
javascriptfunctionreturnprocedure

What happens when returning a procedure in Javascript?

Defining a 'procedure' (if this isn't already the accepted definition) as a function/'subroutine' without a return value (so it's undefined, I guess), such as:

function foo() {
    console.log('something');
}

What happens in something like this:

function a() {
    if (somecondition) {
        return foo();
    }
    // more statements, but no return statement
}
a();

As far as I can tell, someone who would write this just doesn't want to use an else and instead uses the fact that returning from a function prevents the rest from being executed. Is this right? Is there a preferred practice?

Is the line return foo() just syntactic sugar for foo(); return;, since return foo(); == return undefined; == return;? Is this a bad practice, because it isn't exactly clear that the value of foo() is undefined?

At a very low level, what would happen to the return value undefined? a() would just evaluate to undefined and then exist on the stack frame of the parent or global scope as an unassigned value, right? And then it would be garbage collected soon after?

Would this be any different if function a returned a non-undefined value, like 2?

Solution

  • When function a is executing and encounters return foo(), the following takes place:

    1. function a should be paused
    2. a new execution context should be created for function foo on top of the execution stack
    3. function foo should execute within that new execution context
    4. function foo, itself, does not contain any return statements and so, the function will run to completion (assuming there are no errors).
    5. the execution context for foo will be removed from the call stack and all local variables will be de-referenced (assuming that there are no closures preventing this).
    6. execution control will return to function a where it left off (return foo())
    7. since function foo did not return a value, function a executes its return statement but with a value of undefined being returned to the caller of function a.
    8. the execution context for function a is removed from the call stack and all of its local variables are de-referenced (assuming there are no closures preventing it).

    Is the line return foo() just syntactic sugar for foo(); return;, since return foo(); == return undefined; == return;? Is this a bad practice, because it isn't exactly clear that the value of foo() is undefined?

    Would return foo() (when foo() returns undefined) would amount to: foo(); return;, but that doesn't mean that this syntax is "syntactic sugar", it is incorrect syntax that implies that the code is doing one thing, when, in fact, it does something else. This coding style should not be used. Remember, in all of programming, the best-practice is "make code readable". This syntax, when most read it, would cause us to immediatley believe the code is broken as it implies you want to do something (return a value to the caller) that it clearly doesn't do.

    Note: All de-referenced identifiers are immediately available for garbage collection since they are not being assigned anywhere.

    Summary: A function does not take on the value of its return value, that value is simply passed to the caller and it is for the caller to determine what to do with it.

    Even if foo did return a value, your code is:

    a();

    Which does not capture the return value coming out of a() so that value would be immediately garbage collected because it is not being stored anywhere.

    However, if you had written:

    var x = a();

    Then the undefined value would persist in the x variable for as long as x remains in scope.

    The only reason to use return in a function is to terminate the function early (a return all by itself will do this) or to terminate execution but do it while passing an "output" parameter of sorts to the caller. If you have a function that is purely procedural (that is, it does work but does not produce a value result), there is no reason to include return. In fact, the unnecessary use of return is discouraged as it makes the code more difficult to read and introduces the possibility of bugs due to a misunderstanding of the code's intent.