| Why developers need to rethink the 'While' loop
By:
Craig Fitzpatrick
- ComputerWorld Canada
(03 Mar 2008)
More and more software is being pushed to Web servers, a “shared hardware” environment where one little error can pin the CPU and ruin it for everyone. A Canadian ISV has a proposal I think the “While” loop in programming languages needs a refresh. More and more software is being pushed to Web servers, which is essentially a “shared hardware” environment. Which means one little runaway endless loop can pin the CPU and ruin it for everyone (sometimes, thousands of other users). Sure, if set up properly, the Web server should be killing the process after, say, a minute, but then it’s a hard quit and the application doesn’t get a chance to do any sort of recovery. With desktop software, this is much less of an issue because the one and only user will notice a hung process and has a few options (wait & hope, kill it, exit other apps first, then kill it, etc.) While loops are the biggest culprit. Sometimes whatever is inside the loop is complex enough that it’s possible to miss a case that should trigger the loop ending. From a defensive coding point of view, every While loop I code has a check for some reasonable maximum number of loops. If that limit is hit, it throws an endless loop exception. It’s usually easy to pick some number that is so high that under normal circumstances will never be hit, but in the case of a bug, you can hit 10,000 or so loops in about 200 milliseconds and break out of the loop before users notice. I can’t tell you the number of times that practice has worked. It means you get an exception thrown (which you can catch and report), rather than a pinned CPU and unresponsive Web server. It works so well and costs so little (think of a really big number that your loop should not normally hit under regular circumstances), that I would love to see a new mandatory parameter built into While loops: maximum loops. Something like: While (ThisDate < ThatDate; max: 100000) { } Even if the “max” parameter allowed for some constant such as “unlimited”, at least with the compiler enforcing the presence of that parameter, it forces us as developers to remember that what we’re doing has an endless loop as a potential side effect — which in the case of a server-based application, are some of the nastiest possible bugs because they hurt all the other users at the time as well. Fitzpatrick is the CEO of DevShop in Ottawa. This was reprinted with permission from his blog, Uncommon Sense for Software. 
 
Bookmark this article on:
Have something to say about this article? 
If you find a comment inappropriate, You can notify the moderator by clicking the  icon.
| |  | Think back to the "old" days before PCs. Everything ran on mainframes - the ultimate shared hardware platform. But back then, code was more rigorously tested. Perhaps it's time for some "back to the future"? | |
Written by: snaydjoW, from Ottawa | |
| | | Unbelievable! Add something to a command so programmers can't screw up! Give me a break. Perhaps you should be working with people that know what they are doing. If you were working with professionals instead of low grade help you wouldn't have that problem. And what happens when you are running a huge job that ends up consistantly maxing out? Ever worked with large amounts of data? How about keeping the statement just as it is and doing some proper testing, a code walk through, a logic walk through, and stop hiring morons that don't know what they are doing. They give the goods ones a bad name. | |
Written by: Steve, from Thunder Bay | |
| | | It is not uncommon in todays day and age that there exist long running processes. Processes that handle gig's of data, to suggest that the 'while' loop be blamed is just non-sense!
While loops are not worse than For Loops! I have seen For Loops (properly written) behave poorly when the data volume increases. Architecture is key here, while anyone can code, I will go a little further in agreeing with Steve from Thunder Bay in saying that most of the time the 'Analyst' portion of the title is what distinguishes good from bad developers.
Know your limits when you design, then debugging and performance tweaks are minor to retrofit when you notice that your performance is suffering. | |
Written by: Robert Swierczynski, from Edmonton | |
| | | He's not talking about long running processes in terms of time, but rather in terms of cycles.
Pick a limit that is unreasonable ( use 4,000,000,000 if you want ), just code to have an exit.
Steve, as for the morons ... you can't help but hire them today ... let's at least put some boundaries on their code.
I think it is a great idea, and I'll begin coding like this starting today. | |
Written by: Mike, from Regina | |
| | | Many long time developers get away with not needing a max keyword or clause in their code, but this is a positive suggestion that really helps us all. However ... it kinda sounds like a masked for loop (which it is) so maybe the author can make a MACRO (for C/C++) that helps do this task without problems.
...that leaves the 2 million programmers who do not have a clue though... | |
Written by: Abebe, from New York | |
| | | I can't believe all of those who are trying to rip this guy appart. It is not rediculous to add constructs to a language that make it harder for programmers to screw up. Interfaces, Object type casting, etc. There are so many things already in modern languages whose main intent and purpose is to stop the programmer from screwing up. Software engineering is hugely dedicated to the prevention of developer screw-ups.
There's no such thing as a perfect programmer, and you can't fix every bug, so there's no reason in pretending.
Good idea and post, Craig. Interesting concept. | |
Written by: B, from Ottawa | |
| | | Hi gang,
Just noticed the comments! Some further thoughts for those of you kind enough to comment:
"ever heard of testing" > actually there are many types of software defects that are harder to pickup with user testing or unit testing. In many cases, the conditions that cause exiting the loop can be very subtle - and more importantly, the contextual difference between being in a shared environment vs. a dedicated one, is that a pinned CPU is WAY worse than your own application crashing, since now you're affecting everything else running on that box, through no fault of their own
"good programmers don't need this" > statistically speaking, the best programmers are the minority, so from a broader hiring perspective this line of thinking doesn't help. I know a lot of people that think "good" programmers don't need compilers either. But they catch about 90% of the silly things before an app even makes it to testing. | |
Written by: Craig Fitzpatrick, from Ottawa | |
| | | That's a great way to hide bugs until the application begins to scale. Imagine being the 100001th person to file your tax return and you expect a refund! Good luck trying to resolve an endless loop exception when the develper is long gone. "No problem" says the government employee, "I'll just fix that line and recompile the app!" Press 1 to continue... press 1 to repeat... | |
Written by: Dwayne J. Baldwin, from Burlington | |
| | | Wow. Keep the emotions in check folks. All points that have been presented have validity, in one form or another. I don't really think anyone has made a case on either side that warrants name calling or a berating. Those of you who are "superior" programmers and never make mistakes and have all the time and money in the world for testing, obviously have never had to hire contractors and/or been under the gun for delivery dates with less than ideal resources. Craig is on point, in an ideal world there would be no need for tools to reduce/eliminate programming errors. We would all love to be superior programmers and be able to hire only superior programmers but in lieu of a perfect world, we use techniques to use the tools we have and make suggestion on how to improve them. How do you thing improvements that exist today eventually got implemented.
Guys use suggestion like Craig's or don't. Name calling is not warranted. | |
Written by: Eric Wright, from Sarnia | |
| | | Web applications are like putting all the eggs in the same basket. They are not the answer to every need. | |
Written by: micheljq, from Quebec | |
| | | Good article Craig. I'm amazed at comments. Testing does not prove the absence of bugs, only their presence. Proving that a program will halt, in the general case, is very difficult. I have known programmers, in the top 1% of their profession in terms of code reliability, who have written:
for (int i = 0; i < 10000; i++) { // chicken!
while (subtleConditionFromAFarawayPlace()) {
...
}
}
and been rewarded for it!!!!!! | |
Written by: Don Thomson, from Vancouver | |
| | | In general, this is a run-time assert condition. Assertions can be useful at times (extra complex algorithms; complex code that has been modified by other than the author; verification of correct inputs; etc.), but most of the time, it's the code writing attitude that needs to be paid attention to. Languages are much too complex and allow you to do too many things. Imagine if virtually all of your "for" loops started from 0, incremented by 1, and tested for < count. They would all be the same, developers would get used to them and easily spot errors. [In fact, we use this method extensively in house.] Instead, every for loop has to be examined - ok - its starting with 1 or 0 or n, it's incrementing by 1 or -1 or m, the end condition is < or <= or <= count+1 or < count + 1 or > or >=, etc. Which method is going to have the fewest errors and be the easiest to read.
With "while" loops, simply keep your conditions simple. Prove that they will exit (yes by code review, first by yourselt, and then with peers). Keep them simple. (Did I say that already?). Don't use while loops [set the condition at the start of the loop] and until loops [set the condition at the end of the loop]. Stick with the former. It's easier to read code when you know the condition going into a loop.
I don't have a problem with Craig's suggestion to use a production run-time assertion in some places. I do have a problem with it being a standard part of a while loop as it will encourage others not to do their coding work. Testing is another topic, meant to catch bugs. Don't mix it into this discussion because it doesn't apply.
The goal is to write good software, not to catch bugs. If you catch 100 bugs in 10 days from one coding team's output and 9 bugs from another in the same 10 days, which team will you expect to have more buggy software at the end of the day? Think about it. | |
Written by: Joe Farah, from Ottawa, ON | |
| | ADD A COMMENT | |
 | |
|  | |
Digg it
Twitter
Shared hardware is not new, but apparently testing is!
