yes.if set the warning level to /W4.there will be warning.
How to use bool variable.
That's because that assignment has valid uses and coding in an exception for that case would be less productive.
Sure, it's valid, but it's just as (technically) valid as the expression in the if statement. My point was that you can't totally rely on the compiler to warn you if you accidentally make the typo someVar = 42 instead of someVar == 42, and if instead you did 42 == someVar (and then your typo was 42 = someVar), at least you would catch it at compile time. Álvaro's point is good in that the compiler should warn you, but I'm suggesting you can't totally rely on that. My point isn't whether or not the compiler should warn you. Also, I'm not saying one should put the read-only value on the left and the variable on the right; I'm merely pointing out that there is at least some justification for those who choose to do so. I personally don't, but I was originally responding to a post that said "You truly gain nothing from that" which is not quite the case; you gain something, albeit a very small something (but again, that small something may be significant to you or your company's standards).
yes if set the warning level to /W4.there will warning.
Scary. Maybe you should upgrade to a newer VS. I've been using 2008 and it warns about assignments as conditions unless they're placed in braces.
If you turn the warning level in VS 2010 to level 4, it warns "warning C4706: assignment within conditional expression".
In my opinion, using an actual comparison in a conditional clause is more readable than using a Boolean expression without one.
if(ReturnsABool() == false) {...} /* is better than */ if(!ReturnsABool()) {...}
Your sentence should more correctly read 'using an actual boolean-valued comparison expression in a conditional is more readable than using a boolean-valued expression without one. I don't believe this is true, but I believe parsimony is a virtue and one should eschew the obfuscation of unnecessary verbosity and redundancy.
Also, testing a Boolean expression for equality is more readable than testing it for inequality.
if(ReturnsABool() == false) {...} /* is better than */ if(ReturnsABool() != true) {...}
I would phrase that as "positive logic is easier to reason about than negative logic." Alternatively, you could say that it is not easier to reason about negative logic.
Along the same lines, I prefer to pass enumerated values as parameters over integers or Boolean values.
car Car(car::RED); /* is better than */ car Car(0x02); /* or */ car Car(true);
This. Every time.
However, there is a place for well-named boolean variables and functions. Their use in control structures contribute greatly to the readabilty of code.
If find this
while (thread.is_running())
{
// ...
}
quite an improvement over
while (thread.is_running() == true)
{
// ...
}
Try reading them both aloud to see which one makes more sense.
May be the one who gave the advice was thinking of another language, not C++.
For example in Lua this advice can make sense, because "if myBool then" returns true if myBool is assigned any value other than nil or false; while "if myBool == true" will only run if myBool is actually true.
On the other hand "if not myBool" is not the same as "if myBool == false", because the former will test if myBool is either nil (non existent) or false. While the latter will only work if myBool has been explicitly assigned the value "false".
This is a common issue in most dynamically typed languages like Python or Lua.
But in C++ the advice makes little sense, and personally I would suggest "if( myBool )" for all the reasons already stated so far.
if(a) ===> if (a) is true, do the following
if(a==true) ===> if (if (a) is equal to true) is true, do the following
This first one is clear (especially if your variable is properly named), concise, easy to write and easy to read. The second is redundant.
You should use the first in most cases. I'd consider using the second case if the variable, or function, is named in such a way that explicitly adding the "== true" or "== false" actually helps readability, which IMO does sometimes happen.
Using stock warning level in Visual Studio 2012, if I use an assignment operator in the if statement it does not produce a warning and compiles just fine. No complaints from Visual Studio
I actually was programming at about 3 in the morning the other day and made this mistake. Compiler never did warn me and when I went to test it out of course a bug was produced. Though the debugger basically told me what it was because it would end up being an index out of bounds. So the debugger pointed to that line and I immediately saw the mistake of using the assignment operator. I did feel like a complete rookie again.
Though the point just goes on that using stock Visual Studio Warning levels will not produce a warning for it. I would not say it'd be safe to rely on the compiler to warn you about it.
Often getting it wrong and suffering the consequences in my early days of C++ was the best way for me to avoid this typo, along with compiler warnings.
You might want to put a name to the practice of putting the variable last in a comparison. They're "Yoda conditions".
http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html