Are you one of those that don't care about warnings when compiling? Well, if you write Yoda conditions1 like the following, probably you are:
if (2 == foo)
At first, it seems reasonable: if you forget one
= by mistake, the compiler will stop the build with an error, making it obvious that you did something wrong. If the condition was written in the opposite way, it only would present you a warning message. But this approach has a big pitfall: the false sense of security.
If you think that whenever your code compiles without errors it is OK and the warnings are just boring messages that can be easily ignored, you are probably missing the following problem:
if (bar = foo)
Every decent compiler will warn you by telling that, if an assignment is what you really want to do, it's better to surround it with double parenthesis. But if you ignore warnings, you'll get an unexpected (for you) behavior.
In my opinion, compiler warnings are even more important than errors: an error is something that is illegal in the format of a program while a warning is telling you that something looks strange in the logic of your code.
Many warnings are similar to a question: "are you sure you want to do that?" Or better: "doing that you'll get this result: is it what you want?" From my personal experience, many times the answer is "No!"
What If It's Correct?
In case an assignment is what you really want, the already mentioned double parenthesis are what you should use, just like in the following well known snippet:
if ((pid = fork()))
However, I don't like that syntax, since i find it less readable than its split version:
pid = fork(); if (pid)
If you want to be sure that your code won't compile if there are warnings, the flag
-Werror of GCC is what you need.
Image taken from Pexels licensed under the Creative Commons Public Domain Dedication license.
This post has been updated after its initial publication. Last change made on 2016/11/03.