3

Possible Duplicate:
Should a function have only one return statement?

Hello,

gcc 4.4.4 c89

Is it good programming practice to return from 1 point in a function.

I have written a function below. However, I am returning from 2 possible points.

Is this good style?

static int init_data(struct timeout_data_t *timeout_data)
{
    if(timeout_data == NULL) {
        fprintf(stderr, " [ %s ] [ %d ]\n",
            __func__, __LINE__);
        return FALSE;
    }

    /* Assign data */
    timeout_data->seconds = 3;
    timeout_data->func_ptr = timeout_cb;

    return TRUE;
}
Community
  • 1
  • 1
ant2009
  • 27,094
  • 154
  • 411
  • 609
  • 3
    Exact duplicate of the wildly popular [Should a function have only one return statement?](http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement) – James McNellis Jun 30 '10 at 15:23

10 Answers10

11

If it aids readability, then there is nothing wrong with it.

Personally, I write this kind of code all of the time.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
7

This is an ongoing religious-style debate without an accepted answer. There are many people on both sides of the argument, who feel strongly about it.

I don't think there's anything wrong with it personally, but the best approach is to go with the style guidelines of your team, if they have some (and if not, just ask about it. If anyone recoils in horror, it would be kinder to stick to single-return-point).

Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
4

I've had managers that lived and died by the 1 return policy for the sake of "readability", even though it's much more readable in some cases without it.

The bottom line is... if the man that signs your paycheck says you're only going to use 1 return, use 1 return. The best way to do this is

type myfunc(params) {
    type result = defaultValue;
    // actual function here, word for word
    // replace "return $1" with "result = $1"

    return result;
}

This is a valid way to do things in their book, and will smile at your 1 return policy adherence. Of course, you know using this adds ZERO readability because all you've done is replace "return" (which is syntax highlighted) with "result =" which is not. But you've made your boss happy, which when you break it all down is what development is about anyway, right? :-)

corsiKa
  • 81,495
  • 25
  • 153
  • 204
  • +1: my case exactly (our coding standards impose us those rules) – INS Jun 30 '10 at 15:27
  • 1
    This is ... kind of broken advice. Return also stops execution of statements following it, which a simple assignment does not do. So it's not a drop-in solution, at all. – unwind Jun 30 '10 at 15:31
  • 1
    It's not just about readability - there are more important reliability and maintenance issues with multiple return points. – Paul R Jun 30 '10 at 15:46
  • @Paul if your function is so large that multiple return points are not immediately evident, there are even bigger maintenance issues. – corsiKa May 07 '12 at 20:41
2

In straight C, I think that error checking/parameter verification at the top of the function with a return (or possibly even multiple return points in the parameter verification) results in reasonably clean code. After that point, though, my opinion is that it is a good idea to have one single return at the bottom of the function. That helps avoid problems with cleanup (e.g., freeing of memory) that might be allocated in the workings of the function.

Mark Wilkins
  • 40,729
  • 5
  • 57
  • 110
2

There's nothing inherently wrong about having more than one exit point, especially when you're returning on errors. Returning immediately usually makes for clearer code than having the whole thing wrapped in an if/else statement and setting some result flag to be returned at the end. (When you see "return result;", you have to look through all of the earlier code to see how and when result gets set. More moving parts == less clarity.)

cHao
  • 84,970
  • 20
  • 145
  • 172
2

You've tagged your questions as "C" which makes a difference.

In C you might write code such as

open file
process data
close file

If you put a return in the middle of the process data section then you're likely to skip the essential cleanup so it might be considered bad practice to have multiple return points because it's very easy to mess up.

If it was C++ then its best practice to let destructors handle cleanup so it's not nearly such a potential problem so this advice is somewhat obsolete in c++

jcoder
  • 29,554
  • 19
  • 87
  • 130
1

As Oded and Andrzej Doyle pointed out there is nothing wrong with it.

They is no such thing as a golden rule when it comes to this.

The first an most important thing you have to keep in mind when writing code is that some one else will have to read it and make sense out of it. Maybe you will have to go about it in a couple of months, and if you have made a mess you will regret it.

Personally I always:

  • if the code is new used the coding style everybody else is using in the project.
  • If editing others code used the coding style already implemented there.
  • Avoid above all code optimizations (the compiler is best at that).
  • keep it clean and lean.
ntroncos
  • 1,074
  • 9
  • 7
1

If your function is small enough (10-15 lines), as it should be :), then it really doesn't matter if you use a single return point or multiple one. Both are equally readable.

Problems start cropping up with badly designed large functions. In such cases both the styles, returning from a single point, and returning from multiple points, further complicates the function, although even in such cases I prefer returning early and returning at multiple points.

tathagata
  • 478
  • 3
  • 12
1

It's often the case that you have to check for several conditions etc before you start with the real work, and then you are tempted to do an early return, as in your code. I think this is fine for short methods, but when it gets more complicated I'd suggest to break your code in a "setup and check" method and a "real work" method, both having only one exit. Of course as long as it's readeable, it's fine to have multiple returns (e.g. in a long switch statement).

Landei
  • 54,104
  • 13
  • 100
  • 195
1

Failing (and thus returning) early is a very very very good practice. All the code after the checks is free of a lot of potential errors.

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197