4 ms·
> Pick one and go with it. They did. It's `&&` and `||`. I understand your point when it comes to it being a potential landmine, and honestly I never use them
by Smudge 14y ago
> Pick one and go with it.
They did. It's `&&` and `||`.
I understand your point when it comes to it being a potential landmine, and honestly I never use them myself. But I've never seen any ruby guides or docs use `and` instead of `&&`, and I have seen skilled rubyists make great (and correct) use of `and`.
- meepmorp 14y ago> They did. It's `&&` and `||`. I assume you mean idiomatically chosen, since clearly the decision wasn't made at the language level. > I have seen skilled rubyists make great (and correct) use of `and`. I'm obviously not a ruby programmer, so it doesn't matter much to me, but it seems odd to argue that having a largely disused second set of logical operators in a language that skilled people periodically trot out for some cases is anything but a design wart. Maybe it's a cultural thing in the ruby world. And, honestly, I don't mean that to sound snide or slighting. It's just odd to me.
- Smudge 14y agoFair point. It is a bit odd. IIUC the low/reverse-precedence operators came from Perl, and whether or not to use them is just a stylistic choice. It's clear what this means: > raise "ooops" unless do_something() But even so, it reads a bit backwards. Some codebases do this instead: > do_something() or raise "oops" That's just repeating one of the examples in the article, but it jumps out to me as the one I've seen most often.
- NateDad 14y agoI never understood what Perl (and now Ruby) has against if statements. foo or do_something() is exactly the same as if foo { do_something() } Except the latter is WAY less likely to be accidentally misread.... and don't even get me started on do_something() unless foo
- Smudge 14y agoIt's all just a matter of taste and preference. If you find yourself consistently misreading commonplace ruby, maybe ruby isn't for you.