6 ms·
If you're relying on obscure not well known operator precedence rules, you are writing less maintainable code. It's as bad or worse than using meaningless vari
by aneth 16y ago
If you're relying on obscure not well known operator precedence rules, you are writing less maintainable code. It's as bad or worse than using meaningless variable or function names. Use parentheses so your code communicates your intention.
- cageface 16y agoAgreed. It's stuff like this that makes me appreciate lisp.
- brlewis 16y agoThis use of "and" and "or" is exactly what a Lisp programmer would expect. They're used that way a lot in Common Lisp and Scheme.
- lmkg 16y agoThe article isn't talking about the short-circuiting behavior, which I agree is what a Lisper would expect. The article is talking about their operator precedence, and why it's useful to have two sets of operators that are identical except for precedence rules. That is something that you won't find in Lisp, not even buried deep in the guts of LOOP.
- pjscott 16y agoI'm convinced that you can find anything in the guts of LOOP if you look hard enough. Except for an adequate number of parentheses. LOOP doesn't have nearly enough parentheses.
- cageface 16y agoMy point, which downmodders seem to be missing, is that you don't have to rely on the language's magic operator precedence rules in lisp do this kind of thing. The syntax is yours to command.
- ihodes 16y agoIt's funny you say that, because I just used this technique to make a few lines of my Clojure (a Lisp) code a little neater. I find it more readable, and prettier.
- klochner 16y agoIn that spirit, his last example could be improved: foo = cach[:foo] or foo = get_foo() or raise "Could not find foo!" foo = cach[:foo] || get_foo() || raise "Could not find foo!" And I've seen the "foo() and bar()" usage screwed up more than a few times by people not fully understanding the return value of foo()
- GrandMasterBirt 16y agoThis example REALLY illustrates the differences. Very nice.
- KirinDave 16y agoExcept that it's not obscure at all. "and" and "or" exist specifically to facilitate this kind of code. That's their primary purpose. And it's not like that's exactly unusual in the ruby language. Post-conditionals have a similar low precedence.
- acgourley 16y agoIs "this kind of code" worth it? It certainly is aesthetically pleasing and somewhat terse compared to a parenthesis jungle. But that does outweigh the fact non-experts don't know exactly what the statement is doing?
- sketerpot 16y agoTo anyone who learns the idiom, this code is fine, and perfectly readable. I don't even know Ruby yet, and it took me less than a minute to become fully comfortable with this kind of code. This isn't a huge barrier to "non-experts".
- CodeMage 16y agoIt's always easy to claim something is okay when you "don't even know [language] yet", isn't it? ;) All joking aside, the problem with this is not that "non-experts" don't understand what the code does at all. It's that they don't understand all that it does. If you never read anything that warns you about the difference between "and/or" and "&&/||" (or if you skim over it), it can bite you really bad.
- acgourley 16y agoOf course it took under a minute, you were reading a nice blog post on the topic. The problem is not every instance of 'and' will include that information. And so I worry that if I drop 'and' into some minor glue script I write - it becomes less self documenting to my coworkers. It's a minor point, but it can become a slippery slope (see: perl)
- 16y ago
- billybob 16y agoWhat I took away from this is "don't use these in an if statement." Even if I understand how the precedence is different, it isn't obvious at all. It would be better to use more parens to make the evaluation order explicit. The other uses shown, however, were interesting - "or" can be like a one-line if/else. If done right, I think it could be pretty clear.