solution: don't have assignment operator.
Now you're thinking with ~portals~ monads.
HN doesn't support markdown strikethrough, but here's the text in unicode:
p̶o̶r̶t̶a̶l̶s̶
Yoda conditions
61–70 of 116 posts
Re: Yoda conditions
#62Not to mention 'Pokémon exceptions' (catch all)...
In Java at least, you almost can't get away from Pokemoning because of the split between checked and unchecked exceptions. About half of libraries throw checked, and the other half throw unchecked.
Re: Yoda conditions
#63Yeah. when hacking C and C++ into this habit I got. It was hard to break when using other languages.
I've had a lot of feedback from colleagues that it's harder to read because it's rare. If my colleagues say it's hard to read, that's good enough for me.
Re: Yoda conditions
#64It should be noted that Yoda conditions originated at a time when compilers didn't warn about accidental assignment, and linters weren't that great or had poor compatibility. More often than not, the first solution to a problem isn't the best, but the best solution would take a lot of tooling fixes. The Yoda condition trick is a relic of the past, well past its usefulness and best left in its grave alongside Hungaria…
Style lives on, even after the practical purpose for it is no longer relevant. People keep wearing denim, even if they're not working in a mine.
Re: Yoda conditions
#65I know I'm in the minority, but I honestly never really understood why people get so up in arms about this. People keep saying it's so difficult to read, and I just don't understand why. I know that linters and such can catch this most of the time, but a lot of places I've seen don't use them. (I don't know why, that's a whole other discussion.) It just seems to me that it's something that keeps you from wasting time on silly mistakes should be common place. I really don't understand.
Re: Yoda conditions
#66Re: Yoda conditions
#67Yoda conditionals are still very popular in the PHP/Wordpress space. I never got used to using them personally.
Re: Yoda conditions
#68So I'm writing a unit test. I bet everyone here can correctly guess the language.
assert ('Content-Type', 'text/plain') in dupefail.headers
assert b"registration denied" in dupefail.body
assert "403 Forbidden" == dupefail.status
C: 61,11: Comparison should be dupefail.status == '403 Forbidden' (misplaced-comparison-constant)
Please, tell me how much more "natural" and "un-ugly" the 3-line snippet would read to you had it the third line assert flipped away from Yoda style, just as pylint suggests. I'm eager to hear you.
Re: Yoda conditions
#69Earlier quoted context omitted.
Despite the name, it isn't referring to Yoda's grammar form, it's just reversing things around "and" and "or". If you really have a problem telling that "x == y" is the same as "y == x" I suggest coming to a deeper, more complete understanding of the equality operator as a commutative operator where the order doesn't matter rather than thinking of it as "variable is? value", as so many students clearly pick up accide…
There are two perfectly valid ways of reading x == y aloud as an English statement: > X equals Y > X and Y are equal The first sentence uses active voice - the second passive. Active voice ascribes agency to X; It makes a subject/object distinction between X and Y. Passive voice makes them both objects. When reading code, it makes more sense to ascribe agency to variables than to constants, which is why people are mo…
This is exactly the point I'm making; if we must ascribe agency at all (I'm thinking that's a category error here, but human thought is fuzzy and I'll roll with it for now), it would belong to the "==". Don't read it as English at all; read it natively. There is a reason we call these programming languages, no joke, no pun.
"But I do wonder if you’d be equally happy if I went through your codebase and replaced every for loop condition from i i..."
You'd have a hard time of it; I'm a vigorous believer in doing whatever you can in the language you're in to avoid the old 3-element-style C-style for loops in favor of "for ... in ..." or local equivalent. I'm pretty sure you'd get single digit hits for C-style for loops with multiple clauses in the condition.
Re: Yoda conditions
#70I use Yoda style string comparations in java all the time since they are null safe. But other than that I wouldn't have much use for them because they're more difficult to read