|
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 ♫
|
|
|
|
|
|
My Snark Detector is going off.
|
|
|
|
|
No matter how hard I try to find the good in this piece of code, I just can't, I'm sorry.
1st bug: meaningless variable names
2nd bug: No '()' to indicate and clarify precedence
3rd bug: Dead code
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
yes, 1st is not bug, I did it purposely to hide actual busines variables.
2& 3 surely bad.
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
I guest that much. 
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
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 ♫
|
|
|
|
|
|
R. Erasmus wrote: I guest that much.
Did you guest anonymously? - Oh, sorry - the bad-English-and-spelling thread was yesterday ...
|
|
|
|
|
Looks like a test to see if operator==() has been implemented correctly for whatever class the variables A, B, and C are instances of. DoABC() will only be called, if operator==() does not fulfil transitivity.
Of course, there is one error: it should be !A==C instead of A!=C, otherwise we cannot be sure there is an error in operator!=().
Yeah, right... 
|
|
|
|
|
lol. Have 5 for the humor 
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Funny!
I think if you want this code work as your meaning, you should override the operator "==", or you convey it into other language such as C#.
There is some white cloud floating on the blue sky. That's the landscape I like.
|
|
|
|
|
The only minute possibility of it being useful perhaps, is if there are multiple threads involved. . .and maybe if it is the case that A is static or something. . . .that if there was a CPU context switch between the lines
if( A==B ) and
if( B==C && A!=C)
...where A gets changed by another thread therefore the programmer had been trying to be uber careful about running DoABC(). . . . .??
|
|
|
|
|
Are A, B and C all different object types that equate differently?
|
|
|
|
|
This is actually an epic fail I did myself, just yesterday...
I believe I should be punished for this horrible act against humanity so please laugh at me so I never do it again...
Private Sub enableControls()
txtDbHost.Enabled = True
txtDbName.Enabled = True
txtDbPass.Enabled = True
End Sub
Private Sub disableControls()
txtDbHost.Enabled = False
txtDbName.Enabled = False
txtDbPass.Enabled = False
End Sub
Worst thing is that it is part of a project I send into Codecanyon, I really think it's going to get rejected for that blunder.
Henrik Pedersen - HSP Software - www.hsp.dk
|
|
|
|
|
I also do such stuff. What's wrong with it.
I need a slap if there is something wrong with it. 
|
|
|
|
|
You could short it down to something like:
Private Sub SetUIActivated(ByBal Active As Boolean)
control1.Enabled = Active
control2.Enabled = Active
End Sub
|
|
|
|
|
ohh! Such a simple Solution and I never thought. I need to slap myself. 
5 to you!
|
|
|
|
|
Haha and thanks.
But I still committed the crime too :S
|
|
|
|
|
Always think and revisit a piece of code which you just wrote, and you understand how best you can re-write it.
-- Rushi
|
|
|
|
|
Now that is a fail. Shouldn't the routine be called at worst SetUIEnabled or even better EnableControls. The code block doesn't activate anything.
Maybe a more elegant solution would be to iterate through the forms controls and ignore the few controls you wish to remain enabled.
Public Sub EnableControls(ByVal Enabled As Boolean)
For Each FormControl As Control In Me.Controls
FormControl.Enabled = Enabled
Next
End Sub
Personally I didn't see anything wrong with your original solution except that the routine names were lower case.
"You get that on the big jobs."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
