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..

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.

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...

Quote:

---

Originally Posted by Mister C

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by Mister C

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.

Quote:

---

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.

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.

Quote:

---

Originally Posted by Dave_Sinkula

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?

Quote:

---

Originally Posted by brewbuck

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

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.

Quote:

---

Originally Posted by vart

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("%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.