Don't abuse `return`

to_return_or_not_return.js

// BAD: `return` shouldn't be used to control flow/execution
function loadProductData(query) {
	if ($('body').hasClass('busy'))
		return;

	$.ajax( /*...*/ );
}

// GREAT SUCCESS: Just do this instead (OMG duh!)
function loadProductData(query) {
	if (!$('body').hasClass('busy')) {
		$.ajax( /*...*/ );
	}
}

// BAD: Always return if you're going to return
function performScientificMaths(x, y) {
	if (x + y > 0) {
		return x + y;
	}
}

// GREATE SUCCESS: Never a null (I mean, undefined) moment
function performScientificMaths(x, y) {
	if (x + y > 0) {
		return x + y;
	} else {
		return null;
	}
}

I disagree.

function A(q) {
    if(q){
        // 100 lines of code
    }
}

is ugly. I rather have:

function A(q) {
    if(!q){
        return;
    }

    // 100 lines of code
}

I agree that the following is nice

function performScientificMaths(x, y) {
    if (x + y > 0) {
        return x + y;
    } else {
        return null;
    }
}

but why not skip the else all together;

function performScientificMaths(x, y) {
    if (x + y > 0) {
        return x + y;
    }

    return null;
}

Agreed that the else should be omitted.

With the first examples, however, I do dislike return being used to control execution. I know it's something done quite often, but I get annoyed when I'm tracing through code to nail down where things are going wrong, only to find a return plopped right in the middle of a function caused things to halt. I know it's certainly uglier looking.

Maybe I'm being nitpicky.

And I guess in the, albeit rare, case a function is refactored to start actually returning useful values, you're not unexpectedly returning undefined.

Am I grasping at straws yet?