|
It's not clear what problem you're talking about.
--| "Every tool is a hammer." |--
|
|
|
|
|
I think he meant that whatever the result of the actual message sending, the log indicated that the message was successfully sent! This is huge and I can only imagine his reaction when the original dev couldn't fix it!
LOL!
|
|
|
|
|
I always loved seeing something like that. Makes me think the people who wrote it had Attention Deficit Disorder. "OK, we have an important message to send, log that we sent it, now ... Oh!, Look! A spider on the wall!"
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Ah, the infamous spider excuse :P
|
|
|
|
|
Dave Kreskowiak wrote: Makes me think the people who wrote it had Attention Deficit Disorder.
I know exactly what you mean, but please note that there are also people with ADD who CAN program. I know even people who make such mistakes and don't have ADD or a simmilair thing. It's all about to keep your brains under control when you write some serious code.
By the way, most time the people with ADD are comming with the greatest solutions for serious problems. This because they do think more widely and see the problem from perspectives where 'normal' people even don't think about.
So let's respect each other and stay on topic.
|
|
|
|
|
Yeah, and I one of them. If you can't laugh at yourself, who can you laugh at?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Ok, thats making the things different.
For clearness, me 2. Now we can laugh together .
|
|
|
|
|
If only ADD was a factor in the implementation. There was a long winded "explanation" of why the code was implemented that way that contained "and, besides that situation will never happen."
As all good programmers know, if there is even a remotely possible path to a problem, it will occur. Its only a matter of time.
Phil
|
|
|
|
|
This is so minor it probably is a non issue but it bugs me.
If blnFlag = False Then
'Good
Else
Continue
End If This happens alot but I believe it is better to say
If blnFlag = True Then
Continue
End If
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that." - Tommy Boy "Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School)
|
|
|
|
|
The bottom one is definitely better. Anyone who writes code like the first example you posted is confused and either needs a vacation or a book thrown at his face.
█▒▒▒▒▒██▒█▒██
█▒█████▒▒▒▒▒█
█▒██████▒█▒██
█▒█████▒▒▒▒▒█
█▒▒▒▒▒██▒█▒██
|
|
|
|
|
Uhm yeah, I think most developers are guilty of doing something like this at one time or another. It certainly isn't the end of the world. I've seen far worse than this in production code that is currently running around the world.
Phil
|
|
|
|
|
Both examples make me shudder. Why would you compare a boolean to True or False? It IS true or false.
|
|
|
|
|
Absolutely. Along the same lines, my pet peeve is
bool b;
if (condition)
{
b = true;
}
else
{
b = false;
}
what on earth is wrong with
bool b = condition;
Regards
- Roger
|
|
|
|
|
Roger Bamforth wrote: what on earth is wrong with
bool b = condition;
In general I completely agree with you. The only time I might use the "bad" way is for debugging purposes. If I only want a breakpoint to hit when 'condition' is false, then I will create an explicit if/else branch. Of course, after debugging I revert the code back to bool b = condition; (I'm usually too lazy to setup debugger conditions!)
|
|
|
|
|
Yep, done this myself. And debugger conditional breakpoints are actually quite a lot slower than IP traps.
|
|
|
|
|
Well, if the condition is to test the equality of two variables,
bool b;<br><br>if (x = y)<br>{<br> b = true;<br>}<br>else<br>{<br> b = false;<br>}<br>
will give you a compiler warning, and
bool b = (x = y);
will not. (Note the assignment vs equality test bug)
|
|
|
|
|
That's a good point and is actually something that had never occurred to me.
However, whether or not you get a warning depends upon the types of x, y and b is not as simple as it seems. It is probably also language and compiler dependant.
e.g in Visual C++
bool x = true;
bool y = true;
bool b = (x = y);
gives no warning, as you say, but
int x = true;
int y = true;
bool b = (x = y);
does generate a warning (forcing an int to be a bool) and
int x = true;
int y = true;
BOOL b = (x = y);
doesn't.
Regards
- Roger
|
|
|
|
|
Shouldn't it be:
bool b = (x == y);
----------
bool b = (x = y);
would set x to y and then b to x
---
The sum of the intelligence of the world is constant. The total number of people is always increasing.
|
|
|
|
|
It's also quite common. I often find myself starting with the first one, then after testing, stepping through, etc., I refactor to the second.
Kevin
|
|
|
|
|
I think it is just easier to read when you say say what you want it to equal.
If boolean = True instead of just saying
If boolean I just couldnt think of a good example but what I was getting at is really saying something like
If strType = "GOOD" OrElse strType = "COOL" Then
'Good Record
Else
blnError = True
End If instead of saying
If strType <> "GOOD" AndAlso strType <> "COOL" Then
blnError = True
End If
CleaKO
"I think you'll be okay here, they have a thin candy shell. 'Surprised you didn't know that." - Tommy Boy "Fill it up again! Fill it up again! Once it hits your lips, it's so good!" - Frank the Tank (Old School)
|
|
|
|
|
CleaKO wrote: think it is just easier to read when you say say what you want it to equal.
If boolean = True
instead of just saying
If boolean
Funny.
For me its just the opposite: The superfluous = True imposes the nagging feel in me, I have missed something while reading the code.
But then, the whole VB code gives me a screaming fit anyway.
Failure is not an option - it's built right in.
|
|
|
|
|
jhwurmbach wrote: But then, the whole VB code gives me a screaming fit anyway.
I know the feeling.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
jhwurmbach wrote: But then, the whole VB code gives me a screaming fit anyway.
But you see such style in the C-family languages too, though it's probably less common.
Kevin
|
|
|
|
|
Yeah, it's just the opposite for me too. Especially if you name your boolean properties or methods correctly.
If UserIsInRole(user, role) Then
Just the name of the function implies that it returns a True/False value.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
CleaKO wrote: If boolean = True
But then you may have trouble when the code is ported to C, so you really need:
If True = boolean
--| "Every tool is a hammer." |--
|
|
|
|