|| and && bind with the precedence that you expect from boolean operators in programming languages (&& is very strong, || is slightly less strong).
and and or have lower precedence.
For example, unlike ||, or has lower precedence than =:
> a = false || true
=> true
> a
=> true
> a = false or true
=> true
> a
=> false
Likewise, unlike &&, and also has lower precedence than =:
> a = true && false
=> false
> a
=> false
> a = true and false
=> false
> a
=> true
What's more, unlike && and ||, and and or bind with equal precedence:
> !puts(1) || !puts(2) && !puts(3)
1
=> true
> !puts(1) or !puts(2) and !puts(3)
1
3
=> true
> !puts(1) or (!puts(2) and !puts(3))
1
=> true
The weakly-binding and and or may be useful for control-flow purposes: see http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/ .
and has lower precedence than &&.
But for an unassuming user, problems might occur if it is used along with other operators whose precedence are in between, for example, the assignment operator:
def happy?() true; end
def know_it?() true; end
todo = happy? && know_it? ? "Clap your hands" : "Do Nothing"
todo
# => "Clap your hands"
todo = happy? and know_it? ? "Clap your hands" : "Do Nothing"
todo
# => true
I don't know if this is Ruby intention or if this is a bug but try this code below. This code was run on Ruby version 2.5.1 and was on a Linux system.
puts 1 > -1 and 257 < 256
# => false
puts 1 > -1 && 257 < 256
# => true
The Ruby Style Guide says it better than I could:
Use &&/|| for boolean expressions, and/or for control flow. (Rule of thumb: If you have to use outer parentheses, you are using the wrong operators.)
# boolean expression
if some_condition && some_other_condition
do_something
end
# control flow
document.saved? or document.save!
The practical difference is binding strength, which can lead to peculiar behavior if you're not prepared for it:
foo = :foo
bar = nil
a = foo and bar
# => nil
a
# => :foo
a = foo && bar
# => nil
a
# => nil
a = (foo and bar)
# => nil
a
# => nil
(a = foo) && bar
# => nil
a
# => :foo
The same thing works for || and or.
and has lower precedence, mostly we use it as a control-flow modifier such as if:
next if widget = widgets.pop
becomes
widget = widgets.pop and next
For or:
raise "Not ready!" unless ready_to_rock?
becomes
ready_to_rock? or raise "Not ready!"
I prefer to use if but not and, because if is more intelligible, so I just ignore and and or.
Refer to "Using “and” and “or” in Ruby" for more information.
Source: Stackoverflow.com