- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
float TimeLeftSec = TimeLeftFrist + 1;
Admin
Bonus points for the 1f in “0.1f” in the for loop that acts as an IF looking like If.
Admin
Seeing that bad code just makes me want to take a nap.
Admin
Seen logic used with a for loop and smaller sleeps for things in games where the sleep timer can change or feedbacks the remaining cool down to the user(so you'd update the time remaining each loop). Using it recusively inside of a loop is an interesting approach to the problem, I assume someone made a recommendation that sleeps should be threaded to ensure the main thread doesn't get blocked and it was grossly misunderstood.
Admin
Task.Delay...
Admin
do you notice the recursive call?
Admin
I am surprised Remi did not give some bonus points for the recursive implementation of the loop (the return sort of results in a "if", but the recursivity somehow gives the loop-like behavior back.). Or am I missing something?
Maybe the programmer is more comfortable with languages like Scheme (if they feel comfortable in any language).
Admin
Snake? Answer me! Snake! Snaaaaake!
Admin
It's worse than that, in fact, almost no matter how bad you think it is.
In the end, the overall goal is "Schedule a call to
action
after xxx seconds but return immediately after scheduling it", and it's probably the worst possible way to implement that. (It spawns (xxx times ten) number of threads, approximately, one after the other, and calls the action function from the last of them. Not good. And it can't be called again for a different action function before the previous call has happened, seeing as how it uses a global variable for the time remaining.)Admin
The algorithm for figuring out if X number of milliseconds have passed is wonkers. Spawning a thread to sleep is wonkers.
In Java, Thread.sleep can throw an exception to indicate that the thread did not really sleep as long as we requested. The work-around is before the loop, add the desired number of milliseconds to the current time. The condition of the while loop should see if that ending timestamp has passed. The body should sleep (in the current thread) for the difference between the current time and the target timestamp.
Admin
" we attempt to perform the action again."
I missed it reading through the first time, but the "again" is not "execute loop again", but via recursion. Oof.
Admin
Maybe it took that dev a year to write that and he was "let go" immediately afterwards.
Admin
This doesn't really work an can easily end up in a deadlock. Task.StartNew doesn't create a new Thread; it creates a new Task. And a task is basically a scheduled job created on a set of threads. Thread.Sleep sleeps the whole thread, no matter how many tasks are actually run in that context.
TL;DR: Don't do this, never mix threading/parallel/asynchronous operations.
Admin
While the code is horrible there's a good reason for not simply setting the timer for the whole interval--stopping non-cooperating running threads is problematic so you're in a minefield if you set a long timer and they're more prone to running overtime if you set it as one block.
Resetting the timer at 100ms is quite reasonable, how they did it is insane.