Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

paulcoz

"Returning" in middle of loop bad practice?

This topic is 6424 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Just wondering, is it bad practice to "return" in the middle of a loop in a function like this (I've only coded it like I have to show you what I mean). You can see that the first 'return' affects the code flow so that the function quits immediately upon obtaining an answer - is it o.k. to do that in the middle of the while loop (which has not finished)? // check if integer is less than ten bool IntLessThanTen(int intin) { int count = 0; while (count < 10) { if (intin == count) { return 1; // see here } count++; } return 0; } // end IntLessThanTen Paulcoz. Edited by - paulcoz on January 10, 2001 6:35:58 PM

Share this post


Link to post
Share on other sites
Advertisement
Well, that is a horrible example (it wouldn''t even work with negative numbers), but you know that...

There was some debate over that recently. I''m on the side that says immediate returns are fine. You''ll probably find someone who will disagree, somewhere, but most probably agree with me in this case.

Share this post


Link to post
Share on other sites
If what you''re asking is if this sort of thing is acceptable, sure.

  
someclass& MYCLASS::FindInstance(someval what)
{
someclass result;

for (int i=0; i<ItemCount; i++)
{
if (ItemInList[i][1] == someval)
return ItemInList[i][2];
}

return result; // If made to this point, result = NULL...

}



But I personally prefer this method... Just a preference I suppose.

  
someclass& MYCLASS::FindInstance(someval what)
{
someclass result;

for (int i=0; i<ItemCount; i++)
{
if (ItemInList[i][1] == someval)
{
result = ItemInList[i][2];
break;
}
}

return result;
}


Regards,
Jumpster

Share this post


Link to post
Share on other sites
I think the second case is just silly! but as said it's preference.

I think it's better to explicitly call the return as soon as you can. The return sticks out (thanks to color) hence it is easier to locate return paths. If you use an acculator (result), you have not changed the logic of code whatsoever, you have simply changed the color of the word - and made it harder to locate.

The 'one way in, one way out' idea is a load of goulash. The code really doesn't work that way, the design doesn't work that way, and more importantly the RL problems you're solving don't work that way...

People that insist on results, also seem to insist on flowcharts The flowcharts themselves show the non-linearity of the problem.

Perhaps I missed something about the 1-1 idea, but as I understand it, it's not accurate.

...
I thought of a number of cases where I use accumulators. If you're initializing something, and progress through a series of nested if's, you would probably only want one return(hr) at the end.
At the same time, the code may be clearer if you did call an explicit return on an error condition right after each step of the initialization (then you wouldn't need that overly nested if block).
It's hard to say which is better, because they both suck. Is there a better way?
Magmai Kai Holmlor
- The disgruntled & disillusioned


Edited by - Magmai Kai Holmlor on January 10, 2001 9:11:44 PM

Edited by - Magmai Kai Holmlor on January 10, 2001 9:12:55 PM

Share this post


Link to post
Share on other sites

I go with whatever makes sense. I did try to follow the only 1 return in a function rule, but in many cases it simply did not make sense, resulting in messing and bug prone code. If the function''s nature is such that it makes sense to exit in the middle of a loop, then go for it. If you are initializing something like DirectX, you are probably better off with 1 return for whole function (that way you can keep your error handling and stuff straight). Unlike the dreaded GOTO, a return in the middle of the code isn''t as likely to cause memory cleaning up problems AS LONG AS you don''t do anyting too silly and keep your code neat. Hope that helps.

PS: On a totally unrelated note, has GameDev moved to a SLOWER server? I''m having major speed issues with it here, and I''m on cable :/

Share this post


Link to post
Share on other sites
I quite like Jumpster''s break method. At least you feel like you''re cutting the loop short legitimately. I guess it''s just preference though.

I was worried something weird might happen like LordElectro said: ''memory cleaning up problems''.

Paulcoz.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by paulcoz
Just wondering, is it bad practice to "return" in the middle of a loop in a function like this (I''ve only coded it like I have to show you what I mean). You can see that the first ''return'' affects the code flow so that the function quits immediately upon obtaining an answer - is it o.k. to do that in the middle of the while loop (which has not finished)?



Either doing a return in the middle of the function (loop or no loop) or using either ''continue'' or ''break'' is exactly the same as using a ''goto''. Refer to one of the endless ''goto: good or bad'' flame wars for more details

imho, the best option is whatever''s going to make sense to you when you look at it again in 6 months. never using any break/goto/return in he middle of a loop will meet some people''s ideas of a good coding style, but can force horribly convoluted code that''s virtually impossible to understand. code length also matters - if the entire function fits on one screen, it''s easier to follow the code than if you have to constantly use page up/page down to see the whole function. (ie small and complex, or larger but with a simple linear flow.)

one way to check is to count how many paths through a function there are. the higher that number the more complicated it''s likely to be, but there''s no absolue limit - if you break up a function unnaturally then each function may be simple, but the system containing those functions will be complex, meaning the problem wasn''t actually solved.

if all else fails, you''re allowed to comment your code a quick comment can point out that you''re returning from the middle of the loop for a reason, then when you come back to the code, you''ll know what you were trying to do, rather than waste time trying to work it out again.

the short answer to your question is "it depends, but it''s perfectly valid at times."

(incidentally, colour coded code is a good thing, but not always available - printed code doesn''t usually have coloured text, colour blind people read code too - relying on nothing but colour isn''t usually a good plan.)

does that help?

Share this post


Link to post
Share on other sites
There is one more thing though. The asm code for a return is longer than the asm code for a break. So if you are optimizing often used inner loops it can make a difference (loops are faster if they fit into a single 16 byte cache line). But that''s just in extreme cases.

Oh, and I can''t agree with the "return sticking out" thing. All keywords are colored the same in my editor (msvc++). If you have a different editor, then that''s fine.

cu,
Prefect

Share this post


Link to post
Share on other sites
IMHO i would say yes especially if speed is
required however you should ensure that any
newed objects are deleted before returning ie

  

TObject *p = new TObject();

while(i < 10){


if(i == CheckInt){
delete p;
return;
}
}
delete p;



Share this post


Link to post
Share on other sites
IMHO i would say yes especially if speed is
required however you should ensure that any
newed objects are deleted before returning ie

  

TObject *p = new TObject();

while(i < 10){
if(i == CheckInt){
delete p;
return;
}
}
delete p;



Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!