|
Nice piece of work, if wttResultsDataTable is really null application will fail in the first place 
|
|
|
|
|
You cannot be sure... In a multi-threading environment, something bad might happen to the wttResultsDataTable during the calls. Better safe than sorry! 
|
|
|
|
|
You are quite right. The code should be
lock(global_lock_object){
if (wttResultsDataTable.Rows.Count == 1000)
{
if (wttResultsDataTable != null)
{
if (wttResultsDataTable.Rows.Count > 0 && DCTReportRoot.errorFlagRaised == false)
{
|
|
|
|
|
I'm not sure he is being quite cautious enough.
Surely he should add a test to ensure that 1000 is a positive number?
if (!(1000 < 0))
{
...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
You're still taking way to many risks there... Before checking that you should check if false is not true!
if (false != true) { ...The Mayan calendar ends soon, so you'll never know what might happen... At least THIS software won't break 
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
I remember one FORTRAN compiler (GEC 4070 IIRC) where you could write the equivilent of this:
if (1==1)
statement 1
else if (1!=1)
statement 2
else
statement 3 with pretty good confidence that each of the three statements would be executed at some point... 
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: with pretty good confidence that each of the three statements would be executed at some point
I'd love to argue that with you, but I've worked with FORTRAN before. I've seen code I'd swear was dead and refused to remove it just because I've seen things that can't happen, proceed to do so in that language.
|
|
|
|
|
Yeah - COMMON was a good source of "oddities".
I have seen COMMON used to declare a variable as a single integer, and use it as a multidimensional array of floats...
We used to say "Don't like the OS? Use FORTRAN, and change it!"
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: "Don't like the OS? Use FORTRAN, and change it!"
You've just reminded me of my first ever hack. Back in 1964 or thereabouts at Monash Uni, they had a "state of the art" CDC 3200 to which we were allowed to send decks of punched cards. A day or so later, the deck reappeared, hopefully wrapped in a couple of pages of printout. We mere undergrads were limited to IIRC 30 secs run time, which became a bit of a limit on some of our "foreign orders". So, based on a knowledge of the constant absolute address of blank common and a bit of spelunking (find locations in the OS that changed more or less linearly with time...), I wrote an innocent looking FORTRAN subroutine that reset the job timer if it was close to running out. Oh, the joys of unchecked negative array indexes!
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
I remember investigating one application that tried to jump to an invalid location. That app was innocent. Some other code used COMMON to reach what happened to be that program's current memory location, re-wrote the computer instructions including the said jump statement. The app was just running it's instructions when all of a sudden it wasn't their instruction set anymore.
|
|
|
|
|
#define true false
Never trust those booleans!
|
|
|
|
|
IEnumerable<int> finalMarkRange = Enumerable.Range(73,2);
if(finalMarkRange.Contains((int)Math.Round(finalMark,MidpointRounding.AwayFromZero)))
{
...
} 
|
|
|
|
|
That's really much better to understand than
if (finalMark < 74.5 and finalMark >= 72.5) { ... }
Get rid of such complicated math!
|
|
|
|
|
and much slower to execute...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
I'm guessing there's a whole series of such things?
|
|
|
|
|
I think his & key was not working other wise he would have used a && to do it. poor guy.
|
|
|
|
|
I recently started working for a new company and found quite a few situations like this:
Thread m_thread = new Thread(new ThreadStart(GenerateTimeLineImage));
m_thread.Start();
m_thread.Join();
I'm no expert on mulithreading but there are so many different (not just brainless copy-paste) of code like that, that it made me wondering is there some hidden magic behind that code that I'm not aware of.
So, what's the difference between that and
GenerateTimeLineImage();
besides obvious performance loss due to creating a pointless thread?
|
|
|
|
|
I dont think you missed the magic here. I think, you are right that the thread is pointless in this sample.
You should speak to the author of this code if hes still in your company.
|
|
|
|
|
He's not, I'm his replacement... 
|
|
|
|
|
That's why you are replacing him - you can see it.
|
|
|
|
|
That explains everything
|
|
|
|
|
Yes you are right that this code works synchronously albeit using a separate thread. The coder needs to stand in the corner with a dunce cap on.
Cheers! 
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
I think that makes sense in a WinForms app -- if GenerateTimeLineImage takes a bit of time, which seems likely.
|
|
|
|
|
It's not a winforms app, but even it were, it still don't make sense. GenerateTimeLineImage is a heavy function but it would still block the UI thread (if that's why you mentioned WinApp) because of the m_thread.Join() there.
|
|
|
|
|
No, not the least. In that case the UI thread would be waiting until the other thread is finally done. Meanwhile the UI would not respond, just as if the task had been done on the UI thread itself.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
