VB6 and assignment vs. equivalence test operators...
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
How about this?
if constant = value then
flag = true
else
flag = false
end ifSince you can't assign anything to a constant, this is guaranteed to use the comparison = operator :) Oddly enough, I seem to recall this being used in C++ code (with == of course instead of =) "just to be safe"!
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
VB only allows an assignment on the first =. Anny other instance of = is always a compare.
flag = (value = constant)
made perfect sense to me.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
And why <> rather than !=? VB6 is, well, BASIC, maybe the last real BASIC to ever have major importance. VB.NET is CLR and, well, .NET. BASIC does it that way, since BASIC for the Apple II at least, so far as I recall--but then again, my memory isn't so good. What do you think of the := for named parameters?
JonShops -- Fun really begins with the words, "So what in the World do I do now?"
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
I think its just a matter of preference... for me, operator overload in poorly written C++ code is infinitely more confusing than use of = for comparison in VB. :)
-
So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:
if (value = constant) then
flag = true
else
flag = false
end ifSimple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:
flag = (value = constant)
But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:
flag = not(value <> constant)
That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:
flag = (value == test);
/rant
ekolis suggested switching the variables in the long if statement. That left you with the long statement, didn't make sense because the "if" forced equivalency testing, and left me wondering about VB6. CAN you define a constant value in it? (I know it's loosy-goosey about types.) I had no problem understanding the second version, but didn't know why I knew that was correct. Someone else (didn't record who) explained why. That's one of the nice things about coding, you don't have to explain why something will work, just know that it will. Someone coming later may scratch their head, but it gives them a chance to learn something about code they are supposed to know in the first place if they are reading it. The fact that you use "flag" later as a boolian operator will also give them a clue. (Assuming you aren't throwing in random lines of code that doesn't do anything but confuse a reader.) Just because you can do something doesn't mean it's a good idea. I'd want to shoot you myself, if you made "flag" a string, an integer, a floating number, a bool, and just for good measure throw in some "goto" branching. (I can't remember if the last is possible in VB6.)