[sketerpot]

To 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]

It'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]

Of 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)

[KirinDave]

This entire argument is moot. No one cares how obscure a language looks to someone who is not familiar with it. Do you regularly sit down and decide, “I am going to use a language I don't know to accomplish something essential and immediate?” And even if the answer is yes, then do you still not know the language at the end of that exercise?

This is a very simple, easily understandable and easily readable feature of Ruby. It's not obscure, complex, or even that unusual. Precedence is something every competent programmer needs to understand, and it should be part of every programmer's research to learn a new language. After all, this is a conversation about the existence of "and" & "or", not their abuse.

[Roboprog]

I used to be competent, but now I guess I avoid writing stuff that relies on any knowledge of operator precedence.

I try to learn what I can of such precedence in the language of the day, since I will have to maintain other people's "code" (cypher?), but I try to write obvious "programs" (who is in this play, what are the acts?).

I've been at this over 2 decades, and it's much easier to read something that uses a few parentheses, a well named intermediate variable or two, or even a few functions, than it is to read bunch of multiple operators on the same line gobble-de-gook. Watching somebody else generate a hundred thousand dollars of wasted product in a manufacturing preparation process a few years back, due to such a run-on if-statement being fouled up, was also a good confirmation of this bias. I'm sure my current job in finance offers similar opportunities for expensive blunders.