debugging question

[phileo99]

A co-worker told me that it is easier to debug a function that contains
only one return statement versus a function that has multiple return
statements.

Is this true, and if so, why?

 

[kyle york]

Greetings,

A co-worker told me that it is easier to debug a function that contains
only one return statement versus a function that has multiple return
statements.

Others will likely disagree, but using multiple returns is like using
goto's -- it can create unmaintainable speghetti code.

Is this true, and if so, why?

Assuming the return is returning a value, when using a debugger one can
put a breakpoint on the one return and see the value. Alternately, if
not using a debugger one can use a printf() to print the return value.

If you've multiple returns, you'll need to either put a break point at
each one or put a printf by each one.

 

[Alexei A. Frounze]

A co-worker told me that it is easier to debug a function that contains
only one return statement versus a function that has multiple return
statements.

Is this true, and if so, why?

Well, you know... there're a a few phrases "a can of worms" and
"spaghetti-like"... Ever thought how they can be applied to writing code?
Copying and pasting code instead of making a few functions for it, having
many different propagation paths (worse if with complicated logic) and
returns -- all this makes code maintainance and debugging a nightmare, not
immediately, but quickly enough -- try and see.

Alex

 

[Alexei A. Frounze]

Assuming the return is returning a value, when using a debugger one can
put a breakpoint on the one return and see the value. Alternately, if
not using a debugger one can use a printf() to print the return value.
If you've multiple returns, you'll need to either put a break point at
each one or put a printf by each one.

Exactly.
Alex

 

[Walter Roberson]

Others will likely disagree

Assuming the return is returning a value, when using a debugger one can
put a breakpoint on the one return and see the value. Alternately, if
not using a debugger one can use a printf() to print the return value.

If you've multiple returns, you'll need to either put a break point at
each one or put a printf by each one.

It depends on the debugging facilities. The debugger I use most
often has the ability to break upon encountering a return, before
destroying the enclosing scope.

"easier to debug" is relative, and there is no one "right" answer.

Some people say firmly that one should only ever have a single
exit point from a routine, but what they don't always take into account
is that forcing there to be only a single exit point might require
that you convolute your code in ways that make it much harder to
understand.


Suppose, for example, that one is writing a program that has
a mix of possible arguments, some of them incompatible with each
other, and some of which the user might have forgotten to put in.

If one is allowed multiple returns from the code, then one can
use a coding structure such as:

if there is the wrong number of arguments, print a message and exit.

if argument A is given and any of arguments B, Q, or z are given,
print a message and exit

if argument B does not satisfy this mathematical relationship,
print a message and exit

If though, one is not allowed multiple returns, then one ends
up in a long chain of if/then/else, or else one ends up adopting a
make-work scheme such as

set StillValid to True

if there is the wrong number of arguments, print a message and
set StillValid to False.

if StillValid is True and arument A is given and any of the arguments
B, Q, or z are given, print a message and set StillValid to False.

if StillValid is True and argument B does not satisfy this mathematical
relationship, print a message and set StillValid to False.

and so on, at each stage setting a flag whose *only* purpose is to
allow one to (step by step) skip over all remaining code without having
to use a rats-nest of if/else and indentation. And if one examines the
code and finds a particular place that sets the flag, one still has to
read through to the end of the routine, just in case it turns out
that there is something -somewhere- in the routine that proceeds without
regards to whether StillValid is true or not (or in case something
resets it without considering the consequences...). This kind of
code structure can end up being messier than using multiple exits,
and hence using just a single return can end up -harder- to debug,
in some cases.

 

[Michael Mair]

A co-worker told me that it is easier to debug a function that contains
only one return statement versus a function that has multiple return
statements.

Is this true, and if so, why?

The other contributors have given some good reasons why you should
not use multiple return statements.
In some cases, though, some piece of code may call for multiple
exits from a function or a loop (or multiple continue statements).
Imagine a filter:
iterate foo through all bar
{
if (qux(foo))
continue;
baz = bla(foo);
if (quux(baz))
continue;
blub = blib(foo, baz);
if (quuux(blub))
continue;
/* We have valid foo, baz, blub and can start working */
....
}
The alternative is
iterate foo through all bar
{
if (!qux(foo))
{
baz = bla(foo);
if (!quux(baz))
{
blub = blib(foo, baz);
if (!quuux(blub))
{
/* We have valid foo, baz, blub and can start working */
....
}
}
}
}
The same can be imagined for a function
_Bool isValidFoo(foo)
{
if (qux(foo))
return _False;
baz = bla(foo);
if (quux(baz))
return _False;
blub = blib(foo, baz);
if (quuux(blub))
return _False;

return _True;
}
What you prefer is still a matter of taste -- and the above
situation is definitely the exception. If your debugger does
not support stopping just before exiting the function (but
after having determined the return value), then this may be
the argument that demands "single entry, single exit"
everywhere. Even for dispatcher and filter constructions.


Cheers
Michael

 

[Kenneth Brody]

[... Debugging is "easier" with a single return versus multiple returns. ...]

Exactly.

Unless, as I've seen in numerous debuggers, the debugger will step to
the close brace after any return statement.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Mabden]

A co-worker told me that it is easier to debug a function that contains
only one return statement versus a function that has multiple return
statements.

Is this true, and if so, why?

Your friend has read Myers books.

In the days of ForTran, COBOL, and BASIC, the programmers had no
training, no "best practices", etc. And they did "Bad Things" like
jumping into the middle of a subroutine (we call the functions now, and
no one would ever consider jumping into them from the middle of another
function). There were no stacks being setup by the function or anything
to screw up memory, so you could really do this. I remember overlaying
memory locations. If a bit was zero, we used the memory one way, if it
was 1 we used it another way - now C has "union", but back then we just
DID it.

Imagine this:

ftn1(int x)
{
if (global1 == 1) goto ftn2lbl;
x=2;
return x;
}

ftn2(int y)
{
if (y > 0)
goto ftn3;

ftn2lbl:
x=1;
return;
}

Hehehe Imagine what a LINT program would do with the shit we wrote back
then...

 

[Eric Sosman]

Mabden wrote On 09/23/05 08:54,:

A co-worker told me that it is easier to debug a function that
contains

only one return statement versus a function that has multiple return
statements.

Is this true, and if so, why?

Your friend has read Myers books.

In the days of ForTran, COBOL, and BASIC, the programmers had no
training, no "best practices", etc. [...]

Speak for yourself, kid.

<off-topic>

What is this "ForTran" of which you speak? I've used
FORTRAN II and FORTRAN IV and have heard of Fortran, but
this other mixture is something I've never encountered.

</off-topic>