Are we done yet?
Posted on 11/2/09 by Felix Geisendörfer
If you have worked with progress indicators in the past you might have had the same thought that always makes you wonder.
Should I write:
// We are done, move on
}
or should I write:
// We are done, move on
}
that is the question!
Today I went for the '==' route because the $done variable should never be bigger than the $total one.
I think this comes right down to your development philosophy: Should weird conditions in your application that seem "harmless" be silently ignored or should they cause a crash?
I guess I'm the fail often fail early type.
What type are you?
-- Felix Geisendörfer aka the_undefined
Did you like this blog post? If so, please consider subscribing to the Blog RSS feed.
You can skip to the end and add a comment.
Nate: “Broken gets fixed. Shoddy lasts forever.”
Yeah, but read it to the end where he says "Do it right the first time". That does not mean do it wrong and call that 'done'.
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?
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.
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
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.
Steffen: In Visual Basic the way to write "Stable" Software like this was to add a line "On Error Resume Next" on top: p.
On an unrelated note: Is anybody using the new email subscribe feature for blog comments? Does it work?
@felix: It works. :-)
Rob Wilkerson: Sweet! "On Comment Write Next"
@felix -
One enhancement request: how about adding a link to the post and its comments to the email. I don't see such a link so I have to find my way back here. :-)
Apologies for the continued digression. Please continue with your regularly scheduled programmming.
@felix and how about a link to unsubscribe as well :)
Tarique Sani: Unsubscribe? Why would you want to do that? : ). I'll add it soon - sorry for the inconvenience meanwhile. : p
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
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.