Best refactoring for the dreaded While (True) loop

Question

If, like me, you shiver at the site of a While (True) loop, then you too must have thought long and hard about the best way to refactor it away. I\'ve seen several different im

Answer 1

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

Answer 2

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

Think of the Hasselhoff Recursion.

Answer 3

When I encounter a while(true) loop, that 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 as well stick with while(true). (I use for(;;), but that's a style thing in my opinion.) I'm with another poster, why dread this? I dread tortored loops that jump through hoops to get the loop rolled "properly".

Answer 4

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

Answer 5

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

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

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

My preference is to treat a "forever" loop as really just one operating mode -- there 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 some circumstances, nothing we've seen so far sets someMode to False. But I like to pretend that there'll be a mode change in some future version.

Answer 6

My preference would be

start:

   // code goes here

goto start;

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