I'd say you're missing the third option. ;-) Which is to be resilient, or failure-tolerant. Be cognizant of the edge cases or possibilities for failure, but account for them *and recover*. In reality, most exceptional conditions that a web application could run into are *recoverable*, even things like unavailable database connections.

I go the first route, but its more habit as when I started coding, you couldn't trust floating point numbers to be correct, and I got smacked early on in programing because of that, the machine read a .05 as .049996... I guess that is one of those learn from your mistakes and I practice it forever, "just in case". (C program on an 16bit processor if anyone remembers those.)

I would go with the >= plain and simple. Why would you build in unnecessary potential for failures that you may never catch once it is released. I've caught errors like that 2 months after deployment, which made our sites perform poorly.

Hope for Good Data, Program for Bad Data. No matter what, it still must work.

I'm a fail loud, fail proud kind of guy. I think Nate's point is inarguable, but it's not always realistic. Things get missed. In your example, I assume that there's no known reason why $done should be greater than $total and that you can't conceive of the edge case that would make it so. Doesn't mean you're right, but it's what you have to work with.

If that's the case, I'd rather have it fail hard and fast so I can analyze the failure and fix the root cause rather than allow it go on doing the right thing for the wrong reason and possibly mask a more harmful issue.

Question - would you make the same choice if it was a while loop instead of an if condition?

picca said
on Feb 12, 2009:

Absolutely the ">=" option. I was told that I should never test this case on "==". Why? Simply because every source code with at least two lines of code (notice that your code fulfils this condition) has at least one bug. And I have to disagree with Rob. "fail hard and fast" depends on how will your app react. I'll assume that it's possible that there is a situation when it's easier to find the bug if that condition passes. Anyway if there is any possibility that your logic will fail at this point (someone adds record to database by hand), make a test if(a>b){}elseif(a==b){}

Tarique Sani: Good question, if it comes to potentially crashing other requests due to a wild-running while loop I'd use >= for sure. Every script shall cause as much damage as it is capable of causing to the user but non onto its fellow scripts or something - Linux Man Page, 3:10 : p.

picca: In my case the user would never see an upload progress indicator finish. This is what I want to happen. Because I consider this case very much fucked up, and if it's just gonna end up in some log file I'll no really fix it ; p.

picca makes a good point and, though we still disagree, I should have been clear about my definition of "fail". Failure is a hard and fast _stop_, not an application running itself into the ground via an infinite loop or resource-sucking process of some sort. If the latter is a possibility, then much more care is required (and that could be the case in this example).

That said, I'm still not a fan of what I'll call "fuzzy programming" - coding for edge cases that should never happen seems like an awfully slippery slope to me. If that kind of case _does_ happen, I want to know that it happened and why it happened so I can understand the behavior pattern and adjust my app for that pattern. In this case, there's a reason that $done exceeded $total and it might have repercussions beyond this particularly conditional.

Or maybe I'm just paranoid.

NOSLOW said
on Feb 12, 2009:

Rob, I agree with the "I want to know that it happened" during development. When it reaches production, I'm not so sure. Should we log it and hope to fix it later? Felix knows this never happens ;)

Speaking of progress indicators, if you're writing them for Windows, you must follow the MS standard 95/5 rule: The last 5% of the progress should take 95% of the time :P

Steffen said
on Feb 12, 2009:

If you want stable software, use stable conditions, use >=. First thing you are taught at an computer science apprenticeship.

NOSLOW, I guess I'm of a mind that production might be the only place you _really_ begin to exercise those edge cases. Unit tests are good, QA is good, but the rubber meets the road in production. That's where real people with no preconceived notions about how the application _should_ function (or maybe just different ones) use the app. In my experience, users often use apps quite differently from the way they were conceived by developers.

If my app isn't meeting their need, I think it's important to know why and adjust for that. If I mask problems, I may be missing important patterns of usage in addition to obscure issues I didn't consider.