Code Quality – Returning True/Nothing Instead of True/False

code-qualityfunctionslanguage-agnosticreturn-type

Is it OK to have a function that returns true/nothing instead of true/false?

My examples use JavaScript, but I'm wondering about the general case, not attached to one specific language.

The subjects of my interest:

Is it OK from the practical side?
Is it OK from the logical side?

I mean, some languages provide too much freedom and personally I don't like it. I think it is better to follow the way how it works in serious languages like C++ and Java, but I never worked with them.

var a = 1;
var b = 2;

function foo() {
    if (a === b)
        return true;
}

if (!foo())
    alert('error');

versus

function foo() {
    if (a === b)
        return true;
    else
        return false;
}

Best Answer

It depends on what you mean by "OK".

In the languages that I'm familiar with that have the capability to do so, a null/nil/undefined value is falsy. That means that it would be interpreted the same as false when used in a Boolean operation like described in the examples. However, I cannot say for absolute certainty that this will apply to all languages for all time. I also cannot say that everyone reading and working on your code will know this, especially if it's their first foray into a language that permits this behavior.

Personally, I prefer more explicit code. Even if it's slightly more verbose or less idiomatic for your given language, easier readability and maintainability is often a superior choice. Like anything, though, it's a tradeoff that must be decided among the team building the software. Often, decisions like this can be codified in the configuration of linters and other static analysis tools and violations can be detected (and sometimes auto-corrected) during the development process.

Related Solutions

C# Coding Style – Declaring Return Variables vs Returning Value Directly

Because I use Resharper with Visual Studio, Ctrl-RV (Or Ctrl-Alt-V, if you use the Resharper/IntelliJ key bindings) turns your first example into your second example. So when I want to debug, I can do that easily enough. And if I forget to put it back then I won't feel bad because Ctrl-RI will put it right back again to make it easier to read.

Seriously, waste your time arguing about more important things. Like where to put your leading braces or spaces vs tabs.

C++ – Why a function returning by address can not be a lvalue

To start off, your code is broken. Returning a reference or the address of a local variable is returning garbage. Never do this. Here I've rewritten your example to return something real.

int xByAddress = 20;
int xByReference = 30;

int* returnByAddress()
{
    return &xByAddress;
}

int& returnByReference()
{
    return xByReference;
}

int main()
{
    returnByReference() = 23; //possible
    int x = 23;
    returnByAddress() = &x; //not a lvalue error 
    *returnByAddress() = 245; //possible

    return 0;
}

In this example, xByReference is assigned the value 23. xByAddress is assigned the value 245. Of course, returnByAddress() = &x; is invalid.

The rule is: functions return rvalues. The only way around this is to return a reference.

returnByAddress() returns a pointer by rvalue. You can deference the pointer to get an lvalue of the thing pointed at.

Following this rule, you can return a reference to the pointer.

int xByAddress = 20;
int *xPointer = nullptr;

int*& returnByPointerReference()
{
    xPointer = &xByAddress;
    return xPointer;
}

int main()
{
    int x = 23;
    returnByPointerReference() = &x; //not a lvalue error     
    return 0;
}

This code changes xPointer to point at the address of x.

Best Answer

Related Solutions

C# Coding Style – Declaring Return Variables vs Returning Value Directly

C++ – Why a function returning by address can not be a lvalue

Related Topic