Comments on: How to Design Early Returns in C++ (Based on Procedural Programming)

By: Rud Merriam

Rud Merriam — Mon, 03 Sep 2018 01:58:00 +0000

An old code curmudgeon here who first wrote FORTAN in ’68 but still doing C++ today for robotics. These examples are both terrible. A few years ago the fallacy of them was illustrated in testing web site certificates. The comment by Vincent Zalzal is much better but is only applicable for booleans. A local variable should be used and set by each “if” and return. That removes the “interrupt flow of code” responsibility of ‘return’ which should never be used.

One of the rules of Structured Programming (SP) was one entry and one exit. Using multiple returns violates that rule by providing multiple exits. Newer paradigms did not replace the rules for SP but extended them.

By: Jonathan Boccara

Jonathan Boccara — Sun, 02 Sep 2018 14:51:00 +0000

In reply to Hel Noisemaker. Yes, you're right Hel. Fixed it, thanks.

By: Daniel

Daniel — Wed, 29 Aug 2018 21:10:00 +0000

Hi, I can’t help but to notice that leap Year requires != 0 comparisions after modulo operation. But in your examples I look at that as pseudocode.
As for me I prefer second approach when blocks in if-statement are short enough. As for leap year I’d use short cirquiting as offered in comments below.
I know Kevlin oftenly uses FizzBuzz example. I’ve watched his talks with pleasure. 🙂

By: Victor Dyachenko

Victor Dyachenko — Wed, 29 Aug 2018 11:16:00 +0000

I like this version more:

bool isLeapYear(int year)
{
return year % 4 == 0 && (year % 100 != 0 || year % 400 == 0);
}

By: jhk

jhk — Wed, 29 Aug 2018 01:35:00 +0000

I think it’s depends on the case.
I would use early return mostly when procedure is out of pre-condition.

assume i wanna property ‘y’ from class ‘X’ through pointer to process. i would do null-check from the beginning.

bool SomeRandomFunctionProcessYtoBool(X* x)
{
if (x == nullptr)
{
//I might add some error logging or check here to track down what happen
return false;
}
if (more preconditions)
{
return false;
}

auto y = x->y;

//do some magic with y and return bool
}

and in this case I would consider early return without ‘else’ is more cleaner. and its is more practical case when we care about early return i think.

By: Hel Noisemaker

Hel Noisemaker — Tue, 28 Aug 2018 20:30:00 +0000

Is it me, or “bool isLeapYear(int year) {if (year % 400){return true;}…” is just plainly wrong? It means “if remainder of year/400 != 0 then it’s leap year” which is wrong, no?

By: Jonathan Boccara

Jonathan Boccara — Tue, 28 Aug 2018 09:45:00 +0000

In reply to Brad Davis. Interesting! It would be nice to make a performance benchmark between the two versions. I'm writing this in my to-do list

By: EvilTeach

EvilTeach — Mon, 27 Aug 2018 17:09:00 +0000

Here is another philosophy, common cases first.

bool isLeapYear(int year)
{
    if (year % 4 != 0)              // For 3 out of 4 years it’s not a leap year (75%) = .75
        return false;
    else
        if (year % 100 != 0)        //     In 1 out of 4 years, 24 out of 25 cases it is not a leap year (25% * 96%) = .24
            return true;
        else
            if (year % 400 != 0)    // But in those 1 out of 4 years, 24 out of 25 cases, 3 out of 4 cases are not leap years (25% * 4% * 75%) = .0075
                return false;
            else
                return true;        // But in those 1 out of 4 years, 24 out of 25 cases, 1 out of 4 cases are leap years. (25% * 4% * 25%) = .0025
                                    // We will all be dead before this fires again.
}

By: jft

jft — Sat, 25 Aug 2018 12:11:00 +0000

For me, if I had to choose, I would always go with code #2. There is no need for an else following a return and for me having the redundant else clauses gets in the way of reading the code – especially if all the if statements are indented! However, this might be a bad example to choose as the function ‘degrades’ to simply

bool isLeapYear(unsigned int year)
{
return ((((year % 4) == 0) && (year % 100)) || ((year % 400) == 0));
}

which I find easier to read than either code #1 or code #2.

I think there is a debate around using multiple returns in a function as some would say that code #1 should be coded as

bool isLeapYear(unsigned int year)
{
bool ret = false;

if ((year % 400) == 0)
ret = true;
else if ((year % 100) == 0)
ret = false;
else if ((year % 4) == 0)
ret = true;

return ret;
}

with just one entry and one exit – which can be ‘simplified to’

bool isLeapYear(unsigned int year)
{
bool ret = false;

if ((year % 400) == 0)
ret = true;
else
if ((year % 100))
if ((year % 4) == 0)
ret = true;

return ret;
}

by only setting ret to true when needed as the default value for ret is false and therefore doesn’t need setting again to false. From this, of, course, the one-line function at the start of this post results.

When I was taught structured programming in the late 1970’s using Pascal, our Professor of Computer Programming taught us that a function should only have one entry and one exit. In c the convention was that tests for error conditions etc at the start of a function could have their own return so as not to impose too many levels of if nesting within the main code of the function. And this is a convention I would still agree with today.

By: Brad Davis

Brad Davis — Fri, 24 Aug 2018 19:09:00 +0000

All of this code puts the 400 test before the 100 test before the 4 test. If your inputs are evenly distributed among an input range then this means that 3 our of every 4 years is going through 2 more branches than it needs to. Why test 1999 against 100 and 400 when you can eliminate it as a possible leap year with a test against 4?