removal of a return statment

This is a discussion on removal of a return statment within the C Programming forums, part of the General Programming Boards category; This question or suggestion involves the use of the return- used here to terminate the code- not as a function ...

  1. #1
    CS Author and Instructor
    Join Date
    Sep 2002
    Posts
    511

    removal of a return statment

    This question or suggestion involves the use of the return- used here to terminate the code- not as a function returning a value.

    This code is found in a C programming book:

    Code:
    void print(int i)
    if (i < 0)
      return;
    printf("&#37;d", i);
    }
    How often do those of you that program professionally in C- use something like this. To me it looks like it behaves just like a break statement and thus can be removed.

    To remove it would you negate the condition or use a conditonal flag.

    How would you all remove the jump statement- here..
    Mr. C: Author and Instructor

  2. #2
    Registered User
    Join Date
    Sep 2006
    Posts
    835
    The alternative is to negate the condition and then put everything after it in a new scope. If there's only one line after the return, it's actually a little more concise this way. However, if there's 50 lines after it, it's better to have one early return than have to put the 50 lines after it in a new scope.

  3. #3
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    I rearly use void functions, I prefer functions returning status code even for the simple ones that never fail - so in the future they can be easely extended without changing the prototype...

    and yes in function I have very often something like
    Code:
    int foo(int bar)
    {
      /* check parameters */
       if(check failed)
           return BAD_PARAMS_STATUS;
    
       /* do init */
       if(init failed)
          return OUT_OF_RESOURSES_STATUS;
    
       /* do the work */
    
       return OK_STATUS;
    }
    in void functions I have the same structure with empty returns...

    The only times then I prefer if/else structure with single return at the end of the funtion - when I need a long deinitialization procedure on any failure before exiting the function...
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,270
    Quote Originally Posted by Mister C View Post
    How would you all remove the jump statement- here..
    I wouldn't. There is nothing wrong with an early return. Restructuring the code by wrapping stuff in conditions is pointless. If the early return was deep inside a bunch of nested loops, this would become a nightmare. Just return if you want.

  5. #5
    Registered User Noir's Avatar
    Join Date
    Mar 2007
    Posts
    218
    How often do those of you that program professionally in C- use something like this.
    Very regularly. I use it to make the intention of my code very clear.
    To remove it would you negate the condition or use a conditonal flag.
    A conditional flag makes the code harder to follow and negating the condition adds unnecessary and often illogical indentation.
    How would you all remove the jump statement- here..
    I wouldn't because there's no reason to, and any of the "solutions" I can think of reduce code quality rather than increase it.

  6. #6
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by Mister C View Post
    How would you all remove the jump statement- here..
    And this, kids, is why you shouldn't ever buy anything from Mister C. Seriously, you can't figure this out?
    Code:
    void print(int i)
    {
        if ( i > -1 )
            printf("%d", i);
    }
    
    void print(int i)
    {
        if ( i >= 0 )
            printf("%d", i);
    }
    I'm not going to go through every single variation on the theme.

    Not to mention the fact that your code wouldn't even compile. Yeah I bet it was "found in a programming book", yours. You can't type three lines without getting an error? What's wrong, need an editor who actually knows C to help you out here?


    Quzah.
    Hope is the first step on the road to disappointment.

  7. #7
    CS Author and Instructor
    Join Date
    Sep 2002
    Posts
    511
    Not to mention the fact that your code wouldn't even compile. Yeah I bet it was "found in a programming book", yours. You can't type three lines without getting an error? What's wrong, need an editor who actually knows C to help you out
    Thanks, Quazh - I realized I had a mistake after I had posted- but I figured why bother to correct- when I was likely to be bashed anyway...by certain people on this board.

    Just wanted to gather what other professionals would do here- you can assume all you want to about my intentions or my knowledge.
    Mr. C: Author and Instructor

  8. #8
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    My opinion: solving problems that have already been solved is a waste of time.

    Code clearly: then both the compiler and the maintenance programmer will be happy.

    Get clever: you better damn well comment, and maintain the comment, clearly.

    Lacking either a problem, verified though profiling or other means, and in no way being incorrect: just leave working code work.


    [rmumble: where kernighan's list again? ...[/mumble]
    [edit]Here.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  9. #9
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,270
    Quote Originally Posted by Dave_Sinkula View Post
    Code clearly: then both the compiler and the maintenance programmer will be happy.

    Get clever: you better damn well comment, and maintain the comment, clearly.
    But what's your opinion of this specific case? Is an early return a clever trick, or something obvious? I think it's more obvious to just return at the point where you want to return, instead of convoluting the logic.

    What about this construct?

    Code:
    datatype *initialize_something()
    {
        datatype *foo = malloc(sizeof(*foo));
        if(foo)
        {
            /* Initialize the foo */
        }
        return foo;
    }
    This code returns NULL if malloc() fails, but not explicitly. But I write stuff like this all the time. Clever or clear?

  10. #10
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by brewbuck View Post
    But what's your opinion of this specific case? Is an early return a clever trick, or something obvious? I think it's more obvious to just return at the point where you want to return, instead of convoluting the logic.
    To me, obvious.

    Quote Originally Posted by brewbuck View Post
    What about this construct?

    Code:
    datatype *initialize_something()
    {
        datatype *foo = malloc(sizeof(*foo));
        if(foo)
        {
            /* Initialize the foo */
        }
        return foo;
    }
    This code returns NULL if malloc() fails, but not explicitly. But I write stuff like this all the time. Clever or clear?
    To me, clear.
    7. It is easier to write an incorrect program than understand a correct one.
    40. There are two ways to write error-free programs; only the third one works.*

  11. #11
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by vart View Post
    I rearly use void functions, I prefer functions returning status code even for the simple ones that never fail - so in the future they can be easely extended without changing the prototype...
    I prefer the "second person pays" principle, where possible. Of course if you're designing an interface between systems then it's a lot hard to change later and can create version conflicts etc.
    But generally I prefer to refactor as and when required.

    In this specific example, it really really should be refactored into:
    Code:
    void print(int i)
    {
        if ( i >= 0 )
            printf("&#37;d", i);
    }
    Forget the back to front logic of "What must NOT be false in order to NOT do this?", in favour of "What must be true in order to this?". It's shorter, and more to the point, for crying out loud!

    I prefer to only use an early return if it prevents a lot of nested if's, and does make things a lot clearer.

    Dave_Sinkula: To me, clear as well. The returned pointer can only be one that came from malloc.
    Btw, along the same lines as that sample... I can't stand it when people write:
    Code:
    if (somePtr == NULL)
        return NULL;
    else
        return somePtr;
    Just write "return somePtr;" dammit!
    An early "return NULL" basically amounts to a rearrangement of the above, hence all the more reason to write it as brewbuck does.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. 6 measly errors
    By beene in forum Game Programming
    Replies: 11
    Last Post: 11-14-2006, 11:06 AM
  2. Another weird error
    By rwmarsh in forum Game Programming
    Replies: 4
    Last Post: 09-24-2006, 11:00 PM
  3. Why only 32x32? (OpenGL) [Please help]
    By Queatrix in forum Game Programming
    Replies: 2
    Last Post: 01-23-2006, 02:39 PM
  4. opengl help
    By heat511 in forum Game Programming
    Replies: 4
    Last Post: 04-05-2004, 02:08 AM
  5. opengl code not working
    By Unregistered in forum Windows Programming
    Replies: 4
    Last Post: 02-14-2002, 10:01 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21