"If you really hate early exits from loops, maybe you should just code the loop's condition differently."

Exactly.

Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper:

http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf

It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example.

    initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)} 
    while true 
        grow S or T to find an augmenting path P from s to t 
        if P = {(Empty Set)} terminate 
        augment on P 
        adopt orphans 
    end while 

In programming this algorithm, sure, I could probably move the first grow before the loop, and grow at the end. But, now its harder to understand, and violates the afore mentioned copy paste rule.

My point is this, take any such "rule" with a grain of salt. There are plenty of examples where it makes sense to do something atypical.

"violates the afore mentioned copy paste rule"

Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.

You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.

One very useful idiom:

while(readLine()) { process lines... }

where readLine() encapsulates the repetition and returns eof as well.

where is the line (to be processed) stored?

In my comment I assumed it's a line in a file and that the termination condition is eof, but you can generalize to any aggregate of items. I'm just combining the test with the increment step so we can use a simple while loop without having to peel the 'first increment' step out of the loop. If that makes any sense :)

Thanks.

I was trying to point out that the idiom becomes while(line=readline()) which I'd rather avoid since = and == often get confused in a conditional.

It would normally be silly to get into this level of detail but I use this so often.

Oh, good point. I am tolerant of globals :). Also of assignment instead of equality in conditionals (with an extra layer of parens to flag their unconventional nature). I've also used class methods where the implicit variable is in this.

Are the costs of function call overhead worth worrying about?

Maybe this is the crux of Dijkstra's original arguments.

Which is more expensive, a few milliseconds of machine time a few million times or a whole bunch of human time once or twice?

Not at all. What I meant was, you're calling the function in two places, instead of in one place (inside the loop). You've pasted that function call. Thus, by all the same logic, you are introducing a possible future headache.