[ACCEPTED]-Best refactoring for the dreaded While (True) loop-while-loop

My preference would be

start:

   // code goes here

goto start;

This most clearly 3 expresses the intent. Good luck getting 2 it past your coding standards. (Wonder 1 how much karma this is going to cost me).

Do we really need to refactor while(true) loops? Sometimes 10 it's a coding standard and most of the developers 9 has got used to this structure. If you have 8 to think hard on how to refactor this code, are 7 you sure it's a good idea to refactor it?

Goto used 6 to be a black sheep in coding standards. I've 5 met algorithms where goto made the code much 4 more readable and shorter. Sometimes it 3 doesn't worth to refactor (or better to 2 use goto).

On the other hand you can avoid while(true) most 1 of the time.

What's so dreaded about it? Try finding 3 a common break condition and refactor it 2 to be the head of the loop. If that's not 1 possible – fine.

When I encounter a while(true) loop, that 6 tells me either

1. the break condition is not easily tested at the top (or bottom) of the loop,
   • there are multiple break conditions,
   • or the prior programmer was too lazy to factor the loop properly.

1 and 2 means you might 5 as well stick with while(true). (I use 4 for(;;), but that's a style thing in my opinion.) I'm 3 with another poster, why dread this? I 2 dread tortored loops that jump through hoops 1 to get the loop rolled "properly".

Replace True with the condition you were 3 going to use to break out of the loop.

In 2 the case of a service or background thread, you 1 might use:

volatile bool m_shutdown = false;
void Run()
{
    while (!m_shutdown)
    { ... }
}

Why refactor? And what is so "dreadful" about 3 this construct? It is widely used, and 2 well understood.

If it ain't broke, don't 1 fix it.

The "running forever" situation is sometimes 22 part of a larger state machine. Many embedded 21 devices (with run-forever loops) don't really 20 run forever. They often have several operating 19 modes and will sequence among those modes.

When 18 we built heat-pump controllers, there was 17 a power-on-self-test (POST) mode that ran 16 for a little while. Then there was a preliminary 15 environmental gathering mode that ran until 14 we figured out all the zones and thermostats 13 and what-not.

Some engineers claimed that 12 what came next was the "run-forever" loop. It 11 wasn't really that simple. It was actually 10 several operating modes that flipped and 9 flopped. There was heating, and defrosting, and 8 cooling, and idling, and other stuff.

My 7 preference is to treat a "forever" loop 6 as really just one operating mode -- there 5 may be others at some point in the future.

someMode= True
while someMode:
    try:
        ... do stuff ...
    except SomeException, e:
        log.exception( e )
        # will keep running
    except OtherException, e:
        log.info( "stopping now" )
        someMode= False

Under 4 some circumstances, nothing we've seen so 3 far sets someMode to False. But I like to pretend that 2 there'll be a mode change in some future 1 version.

#define ever 1
for (;ever;)

?

Meh, just leave it how it is, while (true) is 1 probably as legible as you're going to get..

errr, to be a refactoring.....

• Replace Infinite Loop with Infinite Recursion :-)

well, if 1 you have a language that supports Tail calls....

If you want it to continue indefinitely 12 until a total abortion of program flow, I 11 don't see anything wrong with while (true). I 10 encountered it recently in a .NET data collection 9 service that combined while (true) with 8 thread.sleep to wake up every minute and 7 poll the third-party data service for new 6 reports. I considered refactoring it with 5 a timer and a delegate, but ultimately decided 4 that this was the simplest and easiest-to-read 3 method. 9 times out of 10 it's a clear 2 code smell, but when there's no exit condition, why 1 make things more difficult?

I don't mind it when the infinite loop is 2 contained within a window, and dies with 1 the window.

Think of the Hasselhoff Recursion.