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.'
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.
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).
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.
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.
28 comments
[ 3.0 ms ] story [ 58.1 ms ] threadActually, yeah, it would have been better.
Of course, you also turn all the warnings on.
[1] By "ternary operators" I mean "pretty-printed, non-nested ternary operators".
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.
In any language that's susceptible to this kind of bug, yes. Python and Haskell solve it in different ways.
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.
"Isn't 'Yoda Programming' where you never handle exceptions? Because, you know, there is no 'try'"
Build Team: DAVID! The robot is continuously driving in circles whenever we turn it on. Me: Must be a mechanical issue
http://en.wikipedia.org/wiki/Unusual_software_bug
Folks, conditions != conditionals.
I told them it would get addressed immediately.
It got addressed via an .htaccess file that masked the URL.
Ducks ftw