What he calls yoda conditions is actually considered best practice in C-like languages, as it will result in a compile time error instead of wrong run time behaviour if you forget to type the second equals sign. The name is still funny, but the way he has written it up betrays a certain lack of understanding.
Perhaps I was unclear -- I and probably over half of HN are familiar with that trick already. However, to my knowledge there was no pithy, memorable name for this practice before.
It's a good practice in almost any language, BTW. In scripting languages, the error will either be caught at parse time or maybe at runtime, but at least it will be noticed.
While neither agreeing nor disagreeing with the style of placing the rval on the left and the lval on the right, I'd just like to point out that another way to avoid these errors is to use immutable variables more often.
I often see programmers with a C/C++ background enter the Java world using Yoda conditions, where such practices serve no use.
I used to work with a guy who insisted on using yoda conditions, "just to be sure". This guy would also make sure he'd "null" out all his variables at the end of the method for the same reason.
This is something I learned to do when I first started programming and just continued to do. I didn't think it was that uncommon (I also do this in non c-like languages as well because while it produces a runtime error you won't get incorrect behavior, just breakage).
I'm actually guilty of using Yoda conditions in anything but Lisp. It is now hardwired in my brain since I learned it early. I'm using it for the same reason as all other Yoda conditioners are, -Wall wasn't really an option then since the source code normally spouted 50+ warning lines due to some included header file.
I use them too, but can't figure out if TFA is being derisive or not. I always thought Yoda conditions were good defensive programming, especially in C-type languages.
I use Yoda conditions all the time. Never knew there was a name for it besides 'a good defensive programming convention to keep you from doing something stupid when programming C.'
My favorite is "mechanical issue". I use it all the time whenever the build team on my robotics team blames me (i.e., the coder) for an issue on the robot.
Build Team: DAVID! The robot is continuously driving in circles whenever we turn it on.
Me: Must be a mechanical issue
I've been called out for Yoda conditions with comparisons, but it's actually just number-line order. I.e. instead of writing "x > 0" I write "0 < x", but I read both as "x greater-than 0."
I've just put a web app into production and one of my client's associates is driving me nuts with his "shrug reports" ('A bug report with no error message or “how to reproduce” steps and only a vague description of the problem. Usually contains the phrase "doesn’t work."'). So I really enjoyed this list.
I successfully used a duck when designing a site for my old company, who insisted I place the CMS in the root directory, so users don't get confused when the URL shows up in the address bar.
I told them it would get addressed immediately.
It got addressed via an .htaccess file that masked the URL.
