return in void functions

[Maximus]

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

TIA, Max.

[Arthur Gold]

Maximus wrote:

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

Some will quibble about that stylistically (preferring a single exit
point), but there's nothing wrong with that technique.

[Of course, you could just as easily have written:

void SetMapLayer()
{
if (Map) layer = LAYER_MAP;
}

]

HTH,
--ag

--
Artie Gold -- Austin, Texas

[Ron Natalie]

"Maximus" <ma*******@vide otron.ca> wrote in message news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

In structured code, you'd want to avoid willy nilly returning from inside functions,
but in this case it probably doesn't make any difference. The scary ones are
things like:

void SomeFunc() {
if(...) {
while( ... ) {
if(...) {
try {
if(...) return
...

[Cy Edmunds]

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

TIA, Max.

I don't like your construction for two reasons:

1) It breaks the structured programming "rule" that each function have only
one return point. I put the word "rule" in quotes because I break it myself
anytime I feel like it. But here there is no reason to.

2) It is effectively a double negative. We set layer to LAYER_MAP if !!Map.

Don't you think this is much clearer?

void SetMapLayer()
{
if (Map)
layer = LAYER_MAP;
}

One return point, no double negatives.

Getting back to your original question, I would use return in a void
function if I thought the net effect was to make the code simpler. Example:

void fribble(int thing)
{
if (thing == 0)
return; // explanation of why here
// 15 lines of code here
}

The structured programming version is

void fribble(int thing)
{
if (thing != 0)
{
// 15 lines of code here
}
}

which I think is somewhat less readable, although by no means a serious
mistake.

--
Cy
http://home.rochester.rr.com/cyhome/

[Mike Wahler]

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

This is a matter of 'taste' or 'style'. I prefer to have a
function have only one exit point (not always possible, but
I strive for it.)

I'd write the above as:

void SetMapLayer()
{
if(Map)
layer = LAYER_MAP;
}

which effectively does the same thing.

Also, even if I'd written it as you have, I'd put the 'return'
statement on a separate line:

if( !Map )
return;

layer = LAYER_MAP;

This makes it more quickly obvious (to me at least) that
the 'linear' execution flow is interrupted. I'd probably
also add a comment for more quick visual identification:

if( !Map )
return; /* EXIT POINT */
/* I also like a blank line here */
layer = LAYER_MAP;

Especially if more code is added after the assignment, this
makes the 'return' stand out.

Again, this is all a matter of 'style'. IMO more important that
the actual 'style' you use, is that you use it consistently.

-Mike

[Jeff Schwab]

Mike Wahler wrote:

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void
function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

This is a matter of 'taste' or 'style'. I prefer to have a
function have only one exit point (not always possible, but
I strive for it.)

I'd write the above as:

void SetMapLayer()
{
if(Map)
layer = LAYER_MAP;
}

which effectively does the same thing.

Also, even if I'd written it as you have, I'd put the 'return'
statement on a separate line:

if( !Map )
return;

layer = LAYER_MAP;

This makes it more quickly obvious (to me at least) that
the 'linear' execution flow is interrupted. I'd probably
also add a comment for more quick visual identification:

if( !Map )
return; /* EXIT POINT */
/* I also like a blank line here */
layer = LAYER_MAP;

Especially if more code is added after the assignment, this
makes the 'return' stand out.

Again, this is all a matter of 'style'. IMO more important that
the actual 'style' you use, is that you use it consistently.

-Mike

It's not just a matter of 'style.' Every extra point of return makes
code much harder to debug, since state-validation code to be executed
before a function returns must be duplicated for each point of return.
Take this advice from someone who has learned the error of his ways:
Keep it down to one exit point whenever possible. The only exception to
this rule should be the throwing of exceptions.

Some languages, like Tcl, do have great support for techniques relying
on multiple points of return. C++ is not such a language.

-Jeff

[Andrew]

"Cy Edmunds" <ce******@spaml ess.rochester.r r.com> wrote in message
news:p2******** ***********@twi ster.nyroc.rr.c om...

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

TIA, Max.
I don't like your construction for two reasons:

1) It breaks the structured programming "rule" that each function have

only one return point. I put the word "rule" in quotes because I break it myself anytime I feel like it. But here there is no reason to.

2) It is effectively a double negative. We set layer to LAYER_MAP if !!Map.
Don't you think this is much clearer?

void SetMapLayer()
{
if (Map)
layer = LAYER_MAP;
}

One return point, no double negatives.

Getting back to your original question, I would use return in a void
function if I thought the net effect was to make the code simpler. Example:
void fribble(int thing)
{
if (thing == 0)
return; // explanation of why here
// 15 lines of code here
}

The structured programming version is

void fribble(int thing)
{
if (thing != 0)
{
// 15 lines of code here
}
}

which I think is somewhat less readable, although by no means a serious
mistake.

--
Cy
http://home.rochester.rr.com/cyhome/

ok, help me out here folks, cause I don't quite know how to reply just to
this comment, but here's mine

function which take on the form:
if( !condition ) // did caller do something stupid
{
print error
return
}
else
{
lots of code
}

are to be avoided as I've learned. The reason: runtime inefficiency due to
cpu branch prediction behavior.
If I remember correctly, the cpu will pipeline the code which errors and
exits instead of the typical function
code resulting is a few holes in the pipeline when it has to skip the error
and exit code, but worse - all of the
typical function code will have go into the pipeline "late". I might
suggest either restructing the if statement or
ensuring that your compiler fixes it for you and generates optimized object
code.

Please do correct me if I am wrong, I hate storing incorrect knowledge in my
head.

Andrew

[Clark Cox]

In article <e-*************** *****@comcast.c om>,
"Andrew" <an****@wallser ver.net> wrote:

"Cy Edmunds" <ce******@spaml ess.rochester.r r.com> wrote in message
news:p2******** ***********@twi ster.nyroc.rr.c om...

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a void function as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

TIA, Max.
I don't like your construction for two reasons:

1) It breaks the structured programming "rule" that each function have

only

one return point. I put the word "rule" in quotes because I break it

myself

anytime I feel like it. But here there is no reason to.

2) It is effectively a double negative. We set layer to LAYER_MAP if

!!Map.

Don't you think this is much clearer?

void SetMapLayer()
{
if (Map)
layer = LAYER_MAP;
}

One return point, no double negatives.

Getting back to your original question, I would use return in a void
function if I thought the net effect was to make the code simpler.

Example:

void fribble(int thing)
{
if (thing == 0)
return; // explanation of why here
// 15 lines of code here
}

The structured programming version is

void fribble(int thing)
{
if (thing != 0)
{
// 15 lines of code here
}
}

which I think is somewhat less readable, although by no means a serious
mistake.

--
Cy
http://home.rochester.rr.com/cyhome/

ok, help me out here folks, cause I don't quite know how to reply just to
this comment, but here's mine

function which take on the form:
if( !condition ) // did caller do something stupid
{
print error
return
}
else
{
lots of code
}

are to be avoided as I've learned. The reason: runtime inefficiency due to
cpu branch prediction behavior.

While that may be true on whatever platform you learned on, different
CPU's predict branches differently.But this is completely outside the
scope of the C++ language. Besides, since the compiler is free to
optimize as it sees fit, as long as it doesn't change the actual meaning
of the code, it could very well reverse the order of the "if {...}" and
"else {...}" sections of code upon seeing that the condition is "not"-ed.
If I remember correctly, the cpu will pipeline the code which errors and
exits instead of the typical function
code resulting is a few holes in the pipeline when it has to skip the error
and exit code, but worse - all of the
typical function code will have go into the pipeline "late". I might
suggest either restructing the if statement or
ensuring that your compiler fixes it for you and generates optimized object
code.

Please do correct me if I am wrong, I hate storing incorrect knowledge in my
head.

You may be right for a particular platform, but you are most
assuredly wrong for many of the platforms out there.

[Chris Dams]

Hello,

Jeff Schwab <je******@comca st.net> writes:

It's not just a matter of 'style.' Every extra point of return makes
code much harder to debug, since state-validation code to be executed
before a function returns must be duplicated for each point of return.

This does not sound very severe. It is a matter of seconds to search for
every occurrence of the word "return" in a function and insert a common
line before that. I think conceptually code like

if(whatever)
return;

is very clear and clean. It just means "Do not apply the rest of the
function if condition _whatever_ is met".

Have a good 2004,
Chris Dams

[Peter Koch Larsen]

"Jeff Schwab" <je******@comca st.net> skrev i en meddelelse
news:W9******** ************@co mcast.com...

Mike Wahler wrote:

"Maximus" <ma*******@vide otron.ca> wrote in message
news:rp******** ************@we ber.videotron.n et...

Hi,
I was just wondering, is it good to use return without arguments in a voidfunction as following:

void SetMapLayer()
{
if( !Map ) return;
layer = LAYER_MAP;
}

It works well but it is considered a good programming technic?

This is a matter of 'taste' or 'style'. I prefer to have a
function have only one exit point (not always possible, but
I strive for it.)

I'd write the above as:

void SetMapLayer()
{
if(Map)
layer = LAYER_MAP;
}

which effectively does the same thing.

Also, even if I'd written it as you have, I'd put the 'return'
statement on a separate line:

if( !Map )
return;

layer = LAYER_MAP;

This makes it more quickly obvious (to me at least) that
the 'linear' execution flow is interrupted. I'd probably
also add a comment for more quick visual identification:

if( !Map )
return; /* EXIT POINT */
/* I also like a blank line here */
layer = LAYER_MAP;

Especially if more code is added after the assignment, this
makes the 'return' stand out.

Again, this is all a matter of 'style'. IMO more important that
the actual 'style' you use, is that you use it consistently.

-Mike

It's not just a matter of 'style.' Every extra point of return makes
code much harder to debug, since state-validation code to be executed
before a function returns must be duplicated for each point of return.
Take this advice from someone who has learned the error of his ways:
Keep it down to one exit point whenever possible. The only exception to
this rule should be the throwing of exceptions.

Some languages, like Tcl, do have great support for techniques relying
on multiple points of return. C++ is not such a language.

-Jeff

Actually, C++ has a very nice feature for this - the deterministic execution
of destructors. This one feature is also the reason that the "one exit rule"
in C++ does not have to be taken to serious. In other languages, I would be
far more careful to have only one exit point.

Kind regards
Peter