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.

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.