|
>>I think it's clear that Michael Sync is a Coding Horror!
>>Turn on firebug and you will see it's doing a lot... errors.
this is code horror..
|
|
|
|
|
yep very true 
Regards,
Sylvester G
|
|
|
|
|
Regards,
Satips. ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Walk beside me, and just be my friend. - Albert Camus
|
|
|
|
|
First one:
R=0;
x1=.1;
y1=.05;
x2=.25;
y2=.24;
x3=1.6;
y3=.24;
x4=300;
y4=200;
x5=300;
y5=200;
DI=document.images;
DIL=DI.length;
function A() {
for(i=0; i-DIL; i++) {
DIS = DI[ i ].style;
DIS.position="absolute";
DIS.left=Math.sin(R*x1+i*x2+x3)*x4+x5;
DIS.top=Math.cos(R*y1+i*y2+y3)*y4+y5
}
R++
}
setInterval("A()",5);
void(0);
It gave errors on DIS.position=’absolute’ and setInterval(’A()’,5)
Because ’ != '
|
|
|
|
|
nothing happened... what are we supposed to see?
|
|
|
|
|
Programming wth threads is not easy as many newbies think. A few years back my company was downsized and I had to take ownership of some code written by another programmer. The first thing I had to fix was some resource leaks when a given task was canceled. The task itself happened on a worker thread. The UI thread had a cacel button to cancel the task.
After examining the code, I found the following:
void CTaskProgessDialog::OnCancel()
{
TerminateThread(m_pWorkThread->m_hHandle);
}
void CWorkerThread::DoTask()
{
AcquireResources();
ReleaseResources();
}
|
|
|
|
|
That's a "double horror" - using TerminateThread, and not using RAII for handling resources (admitedly, it wouldn't help in this case, since TerminateThread does not unwind the stack).
I have learned some Erlang[^] recently, and it really made me re-think the way I write multithreaded code.
|
|
|
|
|
As mentioned the termination of a thread should be internal, not with a Terminate command. Set a flag and wait for self-termination. You never know if a thread has a socket or file open, or any other resources. You can't simply say, no thread can ever aquire resources, and with multi-core and multi-processor allowing two simultaneous operations, it is even more difficult to judge if a terminate signal will work without memory leak even with back-to-back aquire()/release() because the terminate can occur in the middle of aquiring, before releasing, or in the middle of releasing. Terminates should all be handled gracefully from inside. The "code that does something" needs to check for a terminate early flag and release resources (if any) and go on. Simply putting aquire/release back to back will not save you. This is a common failure even with experts on threading thinking that back-to-back operations will not be interrupted. It's all a roll of the dice, back to back operations may make you think everything is okay because chances are reduced, but eventually it will show up as a problem, and then it will be difficult to repeat it for debugging.
remember the core premise of threading: thou shalt not commit murder, all threads should be directed to suicide. 
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Sure!
I can't believe how many programmers (even experienced ones) don't know this.
|
|
|
|
|
"thou shalt not commit murder, all threads should be directed to suicide"
 Nice.
Need Another Seven Acronyms...
Confused? You will be...
|
|
|
|
|
Well - just got this code into review (this is the pseudocode version of a 2000 line routine - a coding WTF in its own right):
1. Begin Transaction
2. Update Table 1 with a single value
3. Update Table 1 with another value - to the same row as step 2.
4. Pop up message box to ask user to ring somebody to confirm that it is OK to continue.
5. Update Table 2
6. Commit Transaction The best bit is that the person who coded this, (supposedly an experienced developer), couldn't see that step 4a. User goes out for lunch, means that the transaction could effectively run for an hour or so.
|
|
|
|
|
Pete O`Hanlon wrote: Pop up message box to ask user to ring somebody to confirm that it is OK to continue.
Ohhh .....Thats what called User confirmation .....I thought something different....
Regards,
Sylvester G
|
|
|
|
|
If this transaction wasn't started by the user in some way, imagine if the user went on a holiday. Or quit. 
Cheers,
Vıkram.
After all is said and done, much is said and little is done.
|
|
|
|
|
Begin Transaction
1. Fire contractor
2. Throw out code
3. Rewrite System
Commit
-------------------------------------------
Damian - Insert snappy one-liner here.
|
|
|
|
|
More likely...
Begin transaction
Hire new outsourcing firm
Add more tentacles to existing Codethulu
Commit self to mental hospital
--
You have to explain to them [VB coders] what you mean by "typed". their first response is likely to be something like, "Of course my code is typed. Do you think i magically project it onto the screen with the power of my mind?" --- John Simmons / outlaw programmer
|
|
|
|
|
You assume that this person was a contractor. Hmmmm.
|
|
|
|
|
I hope for sake that his managers wanted to write such code.
Greetings from Germany
|
|
|
|
|
I'm sure I've seen this used as an example in more than 1 place of how NOT to write transaction code. Maybe your guy skip read the chapter and accidentally picked up the wrong flow chart of how to write this stuff. I'm suprised that anyone who has experience with transactions would dream of doing anything other than Begin, Get the job done quick, Get the hell out.
Russell
|
|
|
|
|
I found the following C# code in an existing application I was hired to rewrite..
catch (System.OutOfMemoryException)
{
continue;
}
|
|
|
|
|
Ahhh, yes a true classic.
--
Real programmers don't comment their code. It was hard to write, it should be hard to understand.
|
|
|
|
|
Exquisite gems in programming right?
|
|
|
|
|
How about a new operator in the catch block? 
|
|
|
|
|
I once saw a program that allocated a huge array on startup. When a certain out of memory condition occurred, it freed the array, then performed a shutdown (hoping that the newly available memory would suffice).
I was quite frightened.
Failure is not an option - it's built right in.
|
|
|
|
|
I can just imagine that guy sitting there thinking, "Out of memory... PROBLEM SOLVED!!!111!11one"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
