Missing '=' in if-statement
-
Missing '=' in if-statement : if (myBool = false) // This if-statement will now always return 'true'. System.out.println("This line will now ALWAYS be executed !"); The correct syntax is, of course : if (myBool == false)
A way to avaoid this pitfall is use if (false == bool)...the compiler will flag up an error if you use "=" instead of "==".
-
A way to avaoid this pitfall is use if (false == bool)...the compiler will flag up an error if you use "=" instead of "==".
-
Missing '=' in if-statement : if (myBool = false) // This if-statement will now always return 'true'. System.out.println("This line will now ALWAYS be executed !"); The correct syntax is, of course : if (myBool == false)
full ack. the "if ( constant == variable )" saved my day a lot of times. one is very prone to this error if you switch between languages a lot like me (=/:= and ==/=). at first it is a bit unusual but if you are used to it is perfecly okay. I wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had. IMHO using = in the if-clause is bad style anyway. R
-
full ack. the "if ( constant == variable )" saved my day a lot of times. one is very prone to this error if you switch between languages a lot like me (=/:= and ==/=). at first it is a bit unusual but if you are used to it is perfecly okay. I wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had. IMHO using = in the if-clause is bad style anyway. R
-
but then you end up doing everything backwards and obfuscating the code. I'd rather have one if-statement a year go wrong than have to struggle to read every line of code every day of the year.
Like you I don't like this particular style. However, I never make this mistake. (I make lots of other mistakes, just not this particular one - maybe it's just the way my brain works.:)) Also, ideally we should test conditions by stepping through code and/or unit tests. Though it's not always feasible to do this.
Kevin
-
full ack. the "if ( constant == variable )" saved my day a lot of times. one is very prone to this error if you switch between languages a lot like me (=/:= and ==/=). at first it is a bit unusual but if you are used to it is perfecly okay. I wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had. IMHO using = in the if-clause is bad style anyway. R
pragma codeproject wrote:
wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had
It does :confused:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Missing '=' in if-statement : if (myBool = false) // This if-statement will now always return 'true'. System.out.println("This line will now ALWAYS be executed !"); The correct syntax is, of course : if (myBool == false)
Does the expression
myBool = falsethe valuetrue? :wtf: It's been a long time since I touched any Java, but that can't be true. That would be totally f-ed up!-- Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
-
Does the expression
myBool = falsethe valuetrue? :wtf: It's been a long time since I touched any Java, but that can't be true. That would be totally f-ed up!-- Mit viel Oktan und frei von Blei, eine Kraftstoff wie Benziiiiiiin!
-
Missing '=' in if-statement : if (myBool = false) // This if-statement will now always return 'true'. System.out.println("This line will now ALWAYS be executed !"); The correct syntax is, of course : if (myBool == false)
As someone who uses the Digital Mars C++ compiler (formerly Symantec C++ and before that Zortech or the like) I never get this problem as the compiler always warns of an unintended assignment. If you *do* intend to do an assignement then you need to code: if ((flag=value)==TRUE) ... or similar. I.e. the compiler makes you be explicit about what you're writing.
-
Yes, it just sets the value of 'myBool' to False and after that, the complete statement is evaluated as true.
Oh no. At least in C/C++ the result of the assignment is the right-most value, i.e. false. Similarly,
if (i=2) {...evaluates to 2.Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
Oh no. At least in C/C++ the result of the assignment is the right-most value, i.e. false. Similarly,
if (i=2) {...evaluates to 2.Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
My point is, the conditions 'myBool = false' and 'i=2' are both 'seen' as 'true' as far as the if-statement is concerned. In other words : if (myBool = false) { // This line will always be executed. } if (i = 2) { // This line will always be executed, even if i <> 2. // And, in fact, i will now be 2. }
-
My point is, the conditions 'myBool = false' and 'i=2' are both 'seen' as 'true' as far as the if-statement is concerned. In other words : if (myBool = false) { // This line will always be executed. } if (i = 2) { // This line will always be executed, even if i <> 2. // And, in fact, i will now be 2. }
I understand your point, but I still think you are wrong (at least in C/C++) if (myBool = false) { // this line will never ever be executed, as the statement evaluates to false } if (i = 2) { // this line will always be executed, because the statement will evaluate to 2, which is non-zero and thus true. } if (i = 0) { // this line will not be executed, the statement evaluates to 0 => false } (disclaimer: I'm not on my devel PC right now, so this is from memory. But I'm pretty sure...)
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
I understand your point, but I still think you are wrong (at least in C/C++) if (myBool = false) { // this line will never ever be executed, as the statement evaluates to false } if (i = 2) { // this line will always be executed, because the statement will evaluate to 2, which is non-zero and thus true. } if (i = 0) { // this line will not be executed, the statement evaluates to 0 => false } (disclaimer: I'm not on my devel PC right now, so this is from memory. But I'm pretty sure...)
Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
No, 'i = 2' doesn't evaluate to 2, because this is not a valid comparison-statement (comparison-statements use '=='). So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java.
I guess it's different between C/C++ and java. I will check it in C/C++ (just for the sake of completeness :)) tonight. Untill then, we agree that i = 2 is an assignment, but I'm pretty sure that in C++ this will evaluate to the right-most element, i.e. 2. And 2 is a true value in C/C++. The evaluate-to-rightmost rule also works here:
int i = j = 2;here 2 is assigned to j, and the result of this assignment (i.e. 2) is assigned to i. Anyway, thanks for the discussion!Cheers Steen. "Are you gonna check your makeup when you're done whining?" John Simmons, 05/31/2006
-
pragma codeproject wrote:
wish VS had a compiler warning about "=" in ifs like the codewarrior compiler had
It does :confused:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
tell me where and you'll save my day :) honest, I didn't find it. I usually use warning level on 3, can't go to 4 since a lot of other code (cross platform) creates noise then. R
-
pragma codeproject wrote:
IMHO using = in the if-clause is bad style anyway.
Yeh, I agree with that completely.
When I am king, you will be first against the wall.
Well, I don't. ;-) I code PHP, and I use that pretty often, ie. if ($file_handle = fopen("filename", "r")) { // do something } else { die("File cannot be opened!"); } That part above returns handle if opened (and that resolves TRUE when it's passed into the variable), and an error otherwise (which resolves FALSE). ...I guess You're going to smack me down for using the last for() element for computation, leaving empty {} brackets, too? :P
-
No, 'i = 2' doesn't evaluate to 2, because this is not a valid comparison-statement (comparison-statements use '=='). So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java.
"So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java." in C also, in C++ also, in PHP also etc. The only language I know of where it DOESN'T evaluate ASSIGNMENTS to TRUE is PASCAL (what with assignment operator being := and all...)
-
As someone who uses the Digital Mars C++ compiler (formerly Symantec C++ and before that Zortech or the like) I never get this problem as the compiler always warns of an unintended assignment. If you *do* intend to do an assignement then you need to code: if ((flag=value)==TRUE) ... or similar. I.e. the compiler makes you be explicit about what you're writing.
"if ((flag=value)==TRUE) ... " Now THIS could be adopted as a 'good practice' over that crappy "value == variable" thing! The latter won't work, for example, when You by mistake do something like if (variable_a = variable_b) { ... and since the names can be pretty long (no limits, really), it'd be tough to spot. With the former approach, one'd see the above as NOT being right, not being: if ((variable_a = variable_b) == TRUE) { ... Could be useful. Thanks :) On a side note, I like to do "if (variable_a === variable_b)", so that I can ommit one "=" and still get away with it (I like to be explicit about what I expect to get exactly, especialy with OOP which in itself obfuscates the code in its own way...)
-
"So 'i = 2' is actually an an ASSIGNMENT and the if-statement seems to evaluate assignments to 'true', at least in Java." in C also, in C++ also, in PHP also etc. The only language I know of where it DOESN'T evaluate ASSIGNMENTS to TRUE is PASCAL (what with assignment operator being := and all...)
-
beg to differ, but C and C++ do not evaluate assignments to true. They evaluate to the rvalue. And yes, I just tried it using GCC.
#include int x; int main() { if (x=0) { printf("assignments evaluate to true!\n"); } return 0; }I stand corrected. :-)