I just read Rick DeNatale's article about Ruby's Operator Precedence, in which he mentioned, that Ruby's and and or operators have a weaker precedence than && and || (and also weaker than =). This is similar to Perl's and and or operators, and the reason why I use the following rules of thumb for the use of the different operators in both languages:
Use && and || for expressions (especially more complex ones) like a = a && b || c.
Use and and or instead of
if enabled then do_it end or do_it if enabled as in enabled and do_it.
Or use and and or for very simple expressions as in if a and b then ... end.
Rule 3 exists only, because I think it is slightly more readable to use and or or than && and ||. This advantage goes pretty much away if you have to start using parentheses to render more complex expressions unambiguous. It could as well be dropped.
But in Ruby other than in Perl there is another reason for rule 3:
Ruby's and and or operators have the SAME precedence!
Yeah, you read this right: So, for example, true || true && false # => true,
but true or true and false # => false.
This is a rather surprising (as in unfortunate) peculiarity of Ruby, and I do not think, that it is a good idea. I guess most people are unaware of this issue, and their code does only work by accident - until it stops doing so for unknown reasons. Matz' rationalisation of this behaviour (somewhere on ruby-talk) was "'and' and 'or' don't have different precedence in English either." It didn't convince me then and doesn't convince me now: We don't program in English, because it is too unprecise. Why burden Ruby with the same problem as well?
Previous Topic
