Using Else with blank If
-
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!):josh: My WPF Blog[^]
Yep, done this myself. And debugger conditional breakpoints are actually quite a lot slower than IP traps.
-
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." |--
It is a good idea to place the constant value to the left of the equality symbol in any language that supports them, to catch syntax errors. It just feels so unnatural to type it that way. ;)
INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
-
CleaKO wrote:
think it is just easier to read when you say say what you want it to equal.
If boolean = Trueinstead of just sayingIf booleanFunny. For me its just the opposite: The superfluous
= Trueimposes 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. :rolleyes:
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
-
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." |--
You might still have trouble in C, if you run up against code that uses other non-zero values for "true"...
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN
-
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 Ifinstead 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)If that's how you use booleans, you might as well just use an integer set to 1 or 0 or a string set to "Y" or "N" (or "True" or "False"). How about:
somethingIsWrong = (type <> "GOOD" AndAlso type <> "Cool")With a variable name that clearly expresses the condition represented by the boolean, the comparison to True or False becomes clearly redundant. -
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
Well, if the condition is to test the equality of two variables,
bool b;
if (x = y)
{
b = true;
}
else
{
b = false;
}will give you a compiler warning, and
bool b = (x = y);
will not. (Note the assignment vs equality test bug)
-
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
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 Ifinstead 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)The reason for the first is that some people have a fixation about negative conditionals, such that they will try and avoid them at all costs - such as the cost you describe!
Kevin
-
CleaKO wrote:
think it is just easier to read when you say say what you want it to equal.
If boolean = Trueinstead of just sayingIf booleanFunny. For me its just the opposite: The superfluous
= Trueimposes 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. :rolleyes:
Failure is not an option - it's built right in.
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
-
Well, if the condition is to test the equality of two variables,
bool b;
if (x = y)
{
b = true;
}
else
{
b = false;
}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
-
This is so minor it probably is a non issue but it bugs me.
If blnFlag = False Then
'Good
Else
Continue
End IfThis 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)If there is a complicated method and I want to indicate that I did indeed accomodate both possibilities I will, ocassionaly, leave a blank if. However, I almost never check a boolean variable against a boolean and instead prefer :
if(isFlagSet){ //Some commented out code or not about //Why not used } else if(!isFlagSet){ //Some Actual code ... } else{ //File Not Found }Just kidding with the File not found!
File Not Found
-
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 Ifinstead 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)boolean = Truebut that's a boolean expression again, which could be true.. or false. So to make absoultely clear you want b = true to be true (not false), you writeIf (boolean = True) = Truelather, rinse, repeat :rolleyes:
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Well, if the condition is to test the equality of two variables,
bool b;
if (x = y)
{
b = true;
}
else
{
b = false;
}will give you a compiler warning, and
bool b = (x = y);
will not. (Note the assignment vs equality test bug)