Multiple return statements Vs goto's

[sureshjayaram]

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,

 

[Russell Shaw]

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.

 

[SM Ryan]

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

 

[Achintya]

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

 

[Chris Croughton]

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

 

[CBFalconer]

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

 

[Minti]

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.

 

[Anonymous 7843]

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.

 

[Malcolm]

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.

 

[Christian Kandeler]

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

 

[CBFalconer]

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.

 

[Kevin D. Quitt]

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

 

[Anonymous 7843]

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.

 

[Chris Croughton]

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

 

[Ben Pfaff]

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.

 

[Keith Thompson]

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.

 

[CBFalconer]

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.

 

[SM Ryan]

# 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?

 

[Chris Croughton]

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

 

[Kevin D. Quitt]

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.