Orchid XP v8 <voi### [at] devnull> wrote:
> "Go to considered harmful."

  Some people go to (pun semi-intended) extremes with the structured
programming paradigm and have the firm stance that anything even resembling
'goto' should be avoided, such as 'break', 'continue' and early returns
(iow. the only 'return' that a function can have is at the end of the
function, nowhere else). Likewise no "fall-through" in switch-case blocks
in languages like C (although this has less to do with goto-like statements
and more to do with structured programming).

  Sometimes this principle is good and leads in a natural way to imperative
code that is cleaner, simpler and easier to read. Othertimes, however, it
leads to the contrary. My favorite example is this (C++-like code, but the
same could be written in any imperative language supporting early returns):

Value* MyClass::searchForValue(const Value& value)
{
    for(size_t x = 0; x < mValues.size(); ++x)
        for(size_t y = 0; y < mValues[x].size(); ++y)
            for(size_t z = 0; z < mValues[x][y].size(); ++z)
                if(mValues[x][y][z] == value)
                    return &mValues[x][y][z];
    return 0;
}

  If you want to avoid the early return in that function, you have to
jump through quite many hoops, all of which make the code more complicated,
without making it any more readable.

  As a personal preference, I also prefer writing code like this:

int someFunction(param1, param2, param3)
{
    if(param1_is_not_ok) return error_code1;

    some_code; // code needed to see if param2 is ok
    if(param2_is_not_ok) return error_code2;

    more_code; // needed to see if param3 is ok
    if(param3_is_not_ok) return error_code3;

    significant_amount_of_code;
    return ok_code;
}

  Even though it could perfectly well be written without the early returns:

int someFunction(param1, param2, param3)
{
    int retval = ok_code;

    if(param1_is_not_ok) retval = error_code1;
    else
    {
        some_code; // code needed to see if param2 is ok
        if(param2_is_not_ok) retval = error_code2;
        else
        {
            more_code; // needed to see if param3 is ok
            if(param3_is_not_ok) retval = error_code3;
            else
            {
                significant_amount_of_code;
            }
        }
    }
    return retval;
}

  The more such error situations there could be, the more indentation the
code would require which is not only inconvenient but also IMO makes the
code less readable. (After all, in my preferred form all the error checking
is nicely at the same indentation level, rather than each subsequent check
being indented more than the previous.)

-- 
                                                          - Warp

Post a reply to this message