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

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.

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.

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?

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;  

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;