Multiple return statements Vs goto's

Discussion in 'C Programming' started by sureshjayaram@gmail.com, May 17, 2005.

  1. Guest

    In some functions where i need to return multiple error codes at
    multiple places, I use multiple return statements. Say for ex.
    if (Found == 1)
    {
    if (val == -1)
    return error1;
    }
    else
    {
    if (val2 == -1)
    return error2;
    }
    return success;
    This is just a simple example. My case have lot of conditional
    statements.

    the alternate approach is to use goto statements. Let me know the
    better way of doing this and which is preferrable (multiple return
    statements or Goto's)

    Thanks,
     
    , May 17, 2005
    #1
    1. Advertising

  2. Russell Shaw Guest

    wrote:
    > In some functions where i need to return multiple error codes at
    > multiple places, I use multiple return statements. Say for ex.
    > if (Found == 1)
    > {
    > if (val == -1)
    > return error1;
    > }
    > else
    > {
    > if (val2 == -1)
    > return error2;
    > }
    > return success;
    > This is just a simple example. My case have lot of conditional
    > statements.
    >
    > the alternate approach is to use goto statements. Let me know the
    > better way of doing this and which is preferrable (multiple return
    > statements or Goto's)
    >
    > Thanks,


    With gotos, you can make all the exit points jump to a common point near
    the end of the function, which is useful to place common clean-up code or
    debug statements. If you have multiple return values, you'll need multiple
    goto labels.
     
    Russell Shaw, May 17, 2005
    #2
    1. Advertising

  3. SM Ryan Guest

    # the alternate approach is to use goto statements. Let me know the
    # better way of doing this and which is preferrable (multiple return
    # statements or Goto's)

    Multiple return statements are go-tos.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    If your job was as meaningless as theirs, wouldn't you go crazy too?
     
    SM Ryan, May 17, 2005
    #3
  4. Achintya Guest

    wrote:
    > In some functions where i need to return multiple error codes at
    > multiple places, I use multiple return statements. Say for ex.
    > if (Found == 1)
    > {
    > if (val == -1)
    > return error1;
    > }
    > else
    > {
    > if (val2 == -1)
    > return error2;
    > }
    > return success;
    > This is just a simple example. My case have lot of conditional
    > statements.
    >
    > the alternate approach is to use goto statements. Let me know the
    > better way of doing this and which is preferrable (multiple return
    > statements or Goto's)
    >
    > Thanks,


    Hi,

    Prefer multiple 'return' statements than 'goto'.

    -vs_p...
     
    Achintya, May 17, 2005
    #4
  5. On 16 May 2005 23:05:07 -0700,
    <> wrote:

    > In some functions where i need to return multiple error codes at
    > multiple places, I use multiple return statements. Say for ex.
    > if (Found == 1)
    > {
    > if (val == -1)
    > return error1;
    > }
    > else
    > {
    > if (val2 == -1)
    > return error2;
    > }
    > return success;
    > This is just a simple example. My case have lot of conditional
    > statements.
    >
    > the alternate approach is to use goto statements. Let me know the
    > better way of doing this and which is preferrable (multiple return
    > statements or Goto's)


    There are other approaches which use neither, for instance:

    int function(/* ... */)
    {
    int retval = OK;
    ...
    if (Found == 1)
    {
    if (val == -1)
    retval = error1;
    }
    else
    {
    if (val2 == -1)
    retval = error2;
    }
    if (retval != OK)
    {
    ...
    }
    return retval;
    }

    In general, functions should be small enough that multiple exits are
    either not needed or are easy to understand. It is very rare that goto
    is needed (the exception tends to be in program-generated code).

    Chris C
     
    Chris Croughton, May 17, 2005
    #5
  6. CBFalconer Guest

    Chris Croughton wrote:
    > <> wrote:
    >
    >> In some functions where i need to return multiple error codes at
    >> multiple places, I use multiple return statements. Say for ex.
    >> if (Found == 1)
    >> {
    >> if (val == -1)
    >> return error1;
    >> }
    >> else
    >> {
    >> if (val2 == -1)
    >> return error2;
    >> }
    >> return success;
    >> This is just a simple example. My case have lot of conditional
    >> statements.
    >>
    >> the alternate approach is to use goto statements. Let me know the
    >> better way of doing this and which is preferrable (multiple return
    >> statements or Goto's)

    >
    > There are other approaches which use neither, for instance:
    >
    > int function(/* ... */)
    > {
    > int retval = OK;
    > ...
    > if (Found == 1)
    > {
    > if (val == -1)
    > retval = error1;
    > }
    > else
    > {
    > if (val2 == -1)
    > retval = error2;
    > }
    > if (retval != OK)
    > {
    > ...
    > }
    > return retval;
    > }
    >
    > In general, functions should be small enough that multiple
    > exits are either not needed or are easy to understand. It
    > is very rare that goto is needed (the exception tends to be
    > in program-generated code).


    Another approach is individually discernable errors, signalled by
    bits in a single value. You can define the bits by something like:

    /* define suitably named error bits in a binary sequence */
    enum MYERRORS {NOERROR, ERRB1, ERRB2, ERRB3=4, ERRB4=8|; /* etc */

    enum MYERRORS errors = NOERROR;

    .....

    if (whatever) errors |= ERRB1;
    else if (somethingelse) errors |= ERRB2;
    else { /* all clear so far */
    ....
    if (...) errors != ERRB3;
    ...
    }
    return errors;

    Note that the above can separate parameter checking from dynamic
    things that occur during execution.

    --
    Some informative links:
    news:news.announce.newusers
    http://www.geocities.com/nnqweb/
    http://www.catb.org/~esr/faqs/smart-questions.html
    http://www.caliburn.nl/topposting.html
    http://www.netmeister.org/news/learn2quote.html
     
    CBFalconer, May 17, 2005
    #6
  7. Minti Guest

    wrote:
    > In some functions where i need to return multiple error codes at
    > multiple places, I use multiple return statements. Say for ex.


    Most people pick one approach and stick to it. It is easy to argue that
    greater the number of return statements, greater the number of exit
    points in a function which cause some debugging blues. OTOH it is also
    easy to argue that any bug that can crop up because of multiple return
    statements can also crop up with multiple goto's.

    --
    Imanpreet Singh Arora
     
    Minti, May 17, 2005
    #7
  8. In article <>,
    <> wrote:
    >
    >
    >In some functions where i need to return multiple error codes at
    >multiple places, I use multiple return statements. ...
    >
    >the alternate approach is to use goto statements. Let me know the
    >better way of doing this and which is preferrable (multiple return
    >statements or Goto's)


    It is a matter of personal preference, but one place I worked had
    a coding standard that neither was really acceptible. Programmers
    were instructed to "fall through" using ifs or switches to let
    the program flow naturally to the end of the function. At first
    it seemed kind of forced to write in that style, but it served
    very well when a function has been worked on by five different
    people and grown to 5000+ lines: if the flow is predicable
    and not all "branchy" it's possible to refactor w/o too much pain.

    For the most part I still adhere to the fall-through style, the
    main exception being when writing a function to map from one
    data type to another (e.g. enum to string). These functions
    tend not to grow or change much so a minor conceit is acceptable.
     
    Anonymous 7843, May 17, 2005
    #8
  9. Malcolm Guest

    <> wrote
    > In some functions where i need to return multiple error codes at
    > multiple places, I use multiple return statements. Say for ex.
    > if (Found == 1)
    > {
    > if (val == -1)
    > return error1;
    > }
    > else
    > {
    > if (val2 == -1)
    > return error2;
    > }
    > return success;
    > This is just a simple example. My case have lot of conditional
    > statements.
    >
    > the alternate approach is to use goto statements. Let me know the
    > better way of doing this and which is preferrable (multiple return
    > statements or Goto's)
    >

    The important thing is that code is easy to read.

    If a function has many branches and exit points, it is likely to be long.
    Look at breaking it down so that each case is literally one line, even if
    that means calling a lot of trivial subroutines.

    Once you've made the function as small as possible, choose goto or return
    depending on what seems to you the most readable, as others have said.

    You will sometimes still hear people say that goto is bad. That is true if
    functions are very long. However in short C functions it is just another
    keyword, to be used if natural flow control seems to call for it, but not
    otherwise.
     
    Malcolm, May 18, 2005
    #9
  10. Anonymous 7843 wrote:

    > It is a matter of personal preference, but one place I worked had
    > a coding standard that neither was really acceptible. Programmers
    > were instructed to "fall through" using ifs or switches to let
    > the program flow naturally to the end of the function. At first
    > it seemed kind of forced to write in that style, but it served
    > very well when a function has been worked on by five different
    > people and grown to 5000+ line


    It probably would have been a good idea to include a clause in the coding
    standard not allowing 5000+ lines functions in the first place...


    Christian
     
    Christian Kandeler, May 18, 2005
    #10
  11. CBFalconer Guest

    Christian Kandeler wrote:
    > Anonymous 7843 wrote:
    >
    >> It is a matter of personal preference, but one place I worked had
    >> a coding standard that neither was really acceptible. Programmers
    >> were instructed to "fall through" using ifs or switches to let
    >> the program flow naturally to the end of the function. At first
    >> it seemed kind of forced to write in that style, but it served
    >> very well when a function has been worked on by five different
    >> people and grown to 5000+ line

    >
    > It probably would have been a good idea to include a clause in the
    > coding standard not allowing 5000+ lines functions in the first
    > place...


    In these days of limitless virtual memory we no longer have the
    protection of a limited block size. Systems use to object to
    oversize functions, when the code generator could not hold the
    complete object chunk for fixups, with a "code too complicated" or
    "code too big" error.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, May 18, 2005
    #11
  12. On Wed, 18 May 2005 08:22:00 GMT, CBFalconer <> wrote:
    >In these days of limitless virtual memory we no longer have the
    >protection of a limited block size.


    Who cares about the compiler? No non-trivial 5,000 line function can be comprehensible to any
    reasonable human being. It smacks of micro-optimization not to be calling other functions to do
    the work.

    I believe in stupid code, i.e., simple functions that (generally) do just one thing and can easily
    tested and proven. The cleverness comes from the architecture and the data.

    (Man, I never thought I'd disagree with CB. If, indeed, I am.)

    --
    #include <standard.disclaimer>
    _
    Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
     
    Kevin D. Quitt, May 18, 2005
    #12
  13. In article <428ad8e6$0$79459$>,
    Christian Kandeler <_invalid> wrote:
    >
    >Anonymous 7843 wrote:
    >
    >> ... "fall through" using ifs or switches to let
    >> the program flow naturally to the end of the function. At first
    >> it seemed kind of forced to write in that style, but it served
    >> very well when a function has been worked on by five different
    >> people and grown to 5000+ line

    >
    >It probably would have been a good idea to include a clause in the coding
    >standard not allowing 5000+ lines functions in the first place...


    Irony noted, but I feel compelled to point out that the two standards
    are not in conflict.

    Single-entry single-exit can make it easier to refactor a large function,
    so there is less resistance to the task and it gets performed more
    often, usually long before anything gets to 5000 lines.

    In my experience at least.
     
    Anonymous 7843, May 18, 2005
    #13
  14. On Tue, 17 May 2005 17:59:39 GMT, Anonymous 7843
    <> wrote:

    > It is a matter of personal preference, but one place I worked had
    > a coding standard that neither was really acceptible. Programmers
    > were instructed to "fall through" using ifs or switches to let
    > the program flow naturally to the end of the function. At first
    > it seemed kind of forced to write in that style, but it served
    > very well when a function has been worked on by five different
    > people and grown to 5000+ lines: if the flow is predicable
    > and not all "branchy" it's possible to refactor w/o too much pain.


    Any function[1] with 5000 lines is obscene. I get alarmed when a module
    (.c file, whatever you like to call it) is anywhere near that size. In
    my view (and that of many companies I've worked for) a function which
    won't fit on a reasonable screen (say 50-60 lines) is a candidate for
    splitting, unless it's something like a big switch statement which just
    can't be split reasonably.

    (The original criterion I learned was "fit on a lineprinter page" -- 66
    lines. By coincidence, that's very close to the normal terminal window
    size I use...)

    [1] "All generalisations are wrong."

    > For the most part I still adhere to the fall-through style, the
    > main exception being when writing a function to map from one
    > data type to another (e.g. enum to string). These functions
    > tend not to grow or change much so a minor conceit is acceptable.


    I tend to return early for parameter checks, it saves a lot of nested
    conditionals and is usually clearer than the "fall through to a common
    exit". It really depends on what I find clearest:

    int getIntFromFile(FILE *fp)
    {
    int value;
    if (!*fp || feof(fp))
    return -1;
    /* do whatever */
    return value;
    }

    int getIntFromFile(FILE *fp)
    {
    int value = -1;
    if (*fp && !feof(fp))
    {
    /* do whatever */
    }
    return value;
    }

    "It depends..."

    Chris C
     
    Chris Croughton, May 18, 2005
    #14
  15. Ben Pfaff Guest

    Chris Croughton <> writes:

    > Any function[1] with 5000 lines is obscene.


    [...]

    > [1] "All generalisations are wrong."


    The big exception to this rule, in my experience, is functions
    that consist of a large switch statement. Sometimes even in
    these cases it is better to use a table of function pointers;
    sometimes not.
    --
    Ben Pfaff
    email:
    web: http://benpfaff.org
     
    Ben Pfaff, May 18, 2005
    #15
  16. Kevin D. Quitt <> writes:
    > On Wed, 18 May 2005 08:22:00 GMT, CBFalconer <> wrote:
    >>In these days of limitless virtual memory we no longer have the
    >>protection of a limited block size.

    >
    > Who cares about the compiler? No non-trivial 5,000 line function
    > can be comprehensible to any reasonable human being. It smacks of
    > micro-optimization not to be calling other functions to do the work.
    >
    > I believe in stupid code, i.e., simple functions that (generally) do
    > just one thing and can easily tested and proven. The cleverness
    > comes from the architecture and the data.
    >
    > (Man, I never thought I'd disagree with CB. If, indeed, I am.)


    I don't think you're disagreeing with him. His point is that in the
    old days, the compiler couldn't handle a 5000 line function, and that
    was in some sense a good thing. On modern systems, the compiler will
    happily compile functions that are far too large for human
    comprehension, so we've lost that "protection".

    I presume he was being somewhat facetious. I think that good style
    should be enforced by programmer discipline rather than by arbitrary
    limitations in the compiler.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, May 18, 2005
    #16
  17. CBFalconer Guest

    "Kevin D. Quitt" wrote:
    > CBFalconer <> wrote:
    >
    >> In these days of limitless virtual memory we no longer have the
    >> protection of a limited block size.

    >
    > Who cares about the compiler? No non-trivial 5,000 line function
    > can be comprehensible to any reasonable human being. It smacks of
    > micro-optimization not to be calling other functions to do the work.
    >
    > I believe in stupid code, i.e., simple functions that (generally) do
    > just one thing and can easily tested and proven. The cleverness
    > comes from the architecture and the data.
    >
    > (Man, I never thought I'd disagree with CB. If, indeed, I am.)


    I don't think you are. My point was that in days of yore any
    attempt to compile that 5000 line function would result in the
    fatal error 'code too complicated', or some such.

    if (foo) {
    /* lotsa code */
    }
    bar;

    exercizes something like (in the code generator):

    savelabel = getlabel;
    generatejumponfalse(foo, savelabel);
    .... parse lotsa code ....
    putlabel(savelabel);
    parse(bar);

    and the rawcode mechanism eventually reaches what is caused by
    putlabel. This has to reach back into the generated code and fixup
    the jumponfalse generated earlier. If that is no longer in the
    generators code buffers it just can't do it.

    Yes, we can (and have) devised other methods of doing the fixup.
    But they are all relatively awkward.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
     
    CBFalconer, May 18, 2005
    #17
  18. SM Ryan Guest

    CBFalconer <> wrote:

    # I don't think you are. My point was that in days of yore any

    Mewonders why you feel the need to waste bandwidth
    on off-topic issue such as your personal history.
    Isn't there an alt.folklore.computers group or such?

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    So basically, you just trace.
     
    SM Ryan, May 19, 2005
    #18
  19. On Wed, 18 May 2005 12:19:58 -0700, Ben Pfaff
    <> wrote:

    > Chris Croughton <> writes:
    >
    >> Any function[1] with 5000 lines is obscene.

    >
    > [...]
    >
    >> [1] "All generalisations are wrong."

    >
    > The big exception to this rule, in my experience, is functions
    > that consist of a large switch statement. Sometimes even in
    > these cases it is better to use a table of function pointers;
    > sometimes not.


    I did say, in the same paragraph as the comment about obscenity, "unless
    it's something like a big switch statement which just can't be split
    reasonably". But in that case (sorry!) I'd expect the actual code for
    each case to be very small.

    Chris C
     
    Chris Croughton, May 19, 2005
    #19
  20. On Thu, 19 May 2005 01:17:27 -0000, SM Ryan
    <> wrote:
    >Mewonders why you feel the need to waste bandwidth
    >on off-topic issue such as your personal history.


    Seems to me that his response was a direct answer to my comment.


    >Isn't there an alt.folklore.computers group or such?


    Wow - I'd forgotten about that. But that's for old farts, eh, like me.


    --
    #include <standard.disclaimer>
    _
    Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
     
    Kevin D. Quitt, May 19, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neil Zanella
    Replies:
    8
    Views:
    1,208
    mfmehdi
    Oct 20, 2006
  2. Harry George
    Replies:
    6
    Views:
    417
    Bart Nessux
    Feb 23, 2004
  3. Alexander Stoyakin

    repeated code before multiple return statements

    Alexander Stoyakin, Jul 27, 2007, in forum: C Programming
    Replies:
    14
    Views:
    596
    Keith Thompson
    Jul 29, 2007
  4. Vince
    Replies:
    12
    Views:
    762
    Martin Gregorie
    Jan 21, 2008
  5. John Crichton
    Replies:
    6
    Views:
    270
    John Crichton
    Jul 12, 2010
Loading...

Share This Page