|
I suppose you can't break anything if you don't change anything or do anything. Sounds like JSL to me.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
This little gem comes courtesy of Q&A:
If TextBox9.Text > TextBox8.Text Then
GoTo bob
Else : TextBox9.Text = TextBox8.Text
End If
Bob: Lovely, no?
Not only that, but he wanted to know why it didn't put the largest number in TextBox9 when TextBox9 had "999" and TextBox8 had "1000".
Sometimes, I get the feeling we should ask who these people are learning from, and have a "hall of shame" just for them...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
OriginalGriff wrote: GoTo bob
He came to the right place
|
|
|
|
|
It's about the only thing he did do right!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
I hope he does not read this. Poor guy came here asking for help, but instead he gets flamed in the hall of shame.
Of course it is something to be ashamed of
OriginalGriff wrote: we should ask who these people are learning from
Judging from the code I think this guy's mentor is called Bob
It's an OO world.
|
|
|
|
|
It’s really bad when they don't get even the most basic things. I sincerely hope this was from a beginning student, not someone with a degree in Computer Science.
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
In reality, I have seen people with a masters degree in Computer Science writing this kind of code.
|
|
|
|
|
OriginalGriff wrote:
If TextBox9.Text > TextBox8.Text Then
GoTo bob
Else : TextBox9.Text = TextBox8.Text
End If
Bob:
What I get out of this is that your real name is 'bob'. Wherein lies the mystery?
|
|
|
|
|
Just saw this code at work:
if( A==B )
{
if( B==C && A!=C)
{
DoABC();
}
else
{
DoWork();
}
}
else if (C==A || C == B)
{
DoWork();
}
I have examined, tested over and over, but code never goes or will go to DoABC();
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Woaw that code definitely sucks!
And I'm not sure if you are being serious about this so I will put this explanation anyway...
But it's testing if A equals B and afterwards if B equals C (and that means both A and B equals C)... And then it only calls DoABC if A don't equals C...
|
|
|
|
|
If equality is transitive (and I really hope it is), it can indeed never execute DoABC.
Given A == B and B == C, it follows from transitivity that A == C, so A != C must be false.
|
|
|
|
|
Under normal circumstances equality is transitive; but it also isn't permanent...
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
"isn't permanent"? can you explain that?
|
|
|
|
|
The variables A, B, C may be equal at some point in time, they also are variables, hence their value can change.
See also here[^].
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Don't forget, in at least some languages, you're allowed to override operators. So A's == may not be the same as B's. That might be a path to DoABC.
In the absence of that, though, what he said.
In the presence of that, that's a whole other kind of bad development.
|
|
|
|
|
In any "sane" scenario its pretty obvious that if A==B and B==C then A should equal C therefore DoABC() will never be called.
Still with no more information, it is plausible (even if hideous) to think that DoABC could be called. It just needs some dubious implicit cast operators to do the trick.
|
|
|
|
|
I assume the data types for A, B and C are something basic? With custom operator overloads you could get to DoABC() using the above logic if you really wanted to. But I think you would need to have different data types
I may or may not be responsible for my own actions
|
|
|
|
|
And then you could post a Hall Of Shame regarding implementing IComparable
"You get that on the big jobs."
|
|
|
|
|
Yes they are string(s)
and now i thing to replace this code with just one line DoWork();
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Ravi Sant wrote: replace this code with just one line DoWork();
But what if A != B && A != C && B != C ? The original code won't execute DoWork in that case.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Good Point ..
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
You didn't tell us what types A, B, C are.
They could be some type with the == operator overloaded by something counter-intuitive. They could also be just stupid integers, stored globally, marked volatile, and changing occasionally...
So, yes it looks weird, it probably is a mistake, and OTOH it could function as intended and just be a case of bad, hardly readable, code.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
they are string(s)
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Your tag line is classic
101 little bugs in the code ♫
|
|
|
|
|
♫ Thanks ♫
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|