One of the best bugs I've ever seen was in the game Dungeon Crawl Stone Soup. It's a roguelike, and a venerable old one at that, so the codebase is quite tangled and convoluted, with logic for everything in every corner. One of the worshippable gods in the game is Xom, god of chaos, whose effects are just as likely to kill their worshipers as to help them (frustrating for those who might actually want to win, but always good for a laugh). And somewhere in the main game loop was some bit of logic that was only ever supposed to activate while the player was actively worshiping Xom. Guess how this was accidentally implemented:<p><pre><code> if (you.religion = GOD_XOM) {
</code></pre>
This actually made it to the live test server, where player save files are automatically upgraded to the most recent build, so anyone logging in immediately found themselves infallibly worshiping the god of chaos, every single tick of in-game time (renouncement is futile). Chaos indeed!
Don't do this.<p>In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation.<p>For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.
I'm fond of Yoda conditionals, but not for the commonly cited reasons. Mostly I just like that they promote the interesting/unpredictable part of the comparison to the front. I consider the safety from unexpected assignment, from null pointer exceptions, and the Star Wars reference all to be minor perks.<p>Take this example:<p><pre><code> function handle_request($http){
if("OPTIONS" === $http.request.method){
...
}else if("GET" === $http.request.method){
...
}else if("PUT" === $http.request.method){
...
}else if($http.request.method === "POST"){
...
}
...
}
</code></pre>
Did you read <i>$http.request.method</i> four times? I bet not. Some of you may have read it the first time; I wouldn't have. But to know that the fourth block handled POST requests I made you read to the end of the line. That makes it harder to scan the code looking for the section that you want to change. In production code that I've seen, the predictable side of a comparison is often quite long.<p>What's especially bizarre to me is the reason people give when advocating writing in the last style. Yes, it verbalizes nicely as "Otherwise, if the http request method post, then..." But who internally translates their code to English to understand it? COBOL was designed to read like natural language. Do you enjoy programming in COBOL? If English-like syntax is desirable for code readability, why don't modern programming languages prioritize English-like syntax, too?<p>Greek mathematics got stuck because it remained a verbal, pictorial activity, Moslem "algebra", after a timid attempt at symbolism, died when it returned to the rhetoric style, and the modern civilized world could only emerge —for better or for worse— ... thanks to the carefully, or at least consciously designed formal symbolisms that we owe to people like Vieta, Descartes, Leibniz, and (later) Boole.<p>-- Dijkstra,
In PHP I like using Yoda Conditions because there's a common idiom of testing assignment in the conditional:<p><pre><code> if ($value = getSomeValue()) {
// Safely use value
}
</code></pre>
Yoda Conditions defend nicely against accidents when '=' and '==' can be used legally this way and honestly you get used to reading them pretty quick.
A lot more of similar programming jargon by Jeff Atwood [1]<p>[1] <a href="https://blog.codinghorror.com/new-programming-jargon/" rel="nofollow">https://blog.codinghorror.com/new-programming-jargon/</a>
I was once officially reprimanded for using Yoda conditionals. That was at the same place that required this:<p><pre><code> if( booleanVariable == true )
{
...
}
else if( booleanVariable == false )
{
...
}
else
{
// Typically, this section would include an exact copy
// of one of the above sections, as it was 3 years ago,
// presumably to pad out the SLoC metrics.
}
</code></pre>
That place had its head <i>so far</i> up its own ass....<p>Equivalence is commutative. Please never complain about the order of its operands as "confusing" or "less readable". It just tells me that you're an ass, trying to enforce a coding convention that has no objective reason to exist.
I ran across a bug at $dayjob where someone was clearly trying to use Yoda conditions, but messed up differently:<p><pre><code> if "start" == argv[1]:
....
else if "stop" == argv[1]:
....
else if "reload":
....
else if "status" == argv[1]:
....
</code></pre>
I think it'd be harder to make this mistake with the conditions the right way around. (Also, never mind that the equality bug isn't even possible in Python.)
A similar but arguably more useful version of this is when you have two variables, one of which may be null. Traditionally you issue an if-condition test using the variable user input as the left operand but switching it handles the null case automatically.<p>Ex:<p><pre><code> Foo SOME_CONSTANT = <something-not-null>;
Foo userSuppliedInput = <some-user-input-possibly-null>;
// This can raise an null pointer exception
if (userSuppliedInput.isEquals(SOME_CONSTANT) {
// ...
}
// This can't raise a null pointer exception (assuming isEquals handles nulls properly):
if (SOME_CONSTANT.isEquals(userSuppliedInput) {
// ...
}</code></pre>
I would say that the phrase "Yoda conditions" more appropriately describes Ruby's alternative form of if-statements:<p><pre><code> if x > 0:
y += x
</code></pre>
versus<p><pre><code> y += x if x > 0</code></pre>
Not worth the effort; modern compilers are very helpful with identifying these kinds of slip ups; and they weren't really that common to begin with, not common enough to warrant the attention and energy sucked into this never ending argument. It's a rule for the sake of having rules, like so many others.
I didn't know abut "Yoda conditions," and thought it was going to be those "reversed" if statements that were so startling when I'd started coding in Perl.<p><pre><code> $days = 28 if $month eq "February";</code></pre>
I don't follow this convention, but something I do follow is naming things by type first. This makes it really easy to find in a long list of files in a folder.<p>Example: plantArrowhead, plantGuzmania, plantMarmo vs. arrowheadPlant, guzmaniaPlant, marmoPlant.
Yoda conditions suck. You don't compare a constant to a value of a variable to make sure that the constant has a certain value. Such comparison is backwards. Unfortunately it is extremely popular at Microsoft among C++ programmers. They seem to totally lack any sense of style. Sometime in the nineties the enforcement of Hungarian notation throughout the company had a long lasting damaging effect on their psyche they still can't recover from after all these years.
ESLint has a rule to prevent this.<p><a href="http://eslint.org/docs/rules/yoda" rel="nofollow">http://eslint.org/docs/rules/yoda</a>