The && and || Operators in JavaScript. If applied to boolean values, the && operator only returns true when both of its operands are true (and false in all other cases), while the || operator only returns false when both of its operands are false (and true in all other cases).
Nope. It turns out Ruby just has different precedence rules for and and &&. Now, this example may prompt you to avoid the word versions of the boolean operators altogether, and you wouldn't be alone — the first Google result when searching “Ruby Style Guide” suggests you should never use them.
It's a matter of operator precedence.
||
has a higher precedence than or
.
So, in between the two you have other operators including ternary (? :
) and assignment (=
) so which one you choose can affect the outcome of statements.
Here's a ruby operator precedence table.
See this question for another example using and
/&&
.
Also, be aware of some nasty things that could happen:
a = false || true #=> true
a #=> true
a = false or true #=> true
a #=> false
Both of the previous two statements evaluate to true
, but the second sets a
to false
since =
precedence is lower than ||
but higher than or
.
As the others have already explained, the only difference is the precedence. However, I would like to point out that there are actually two differences between the two:
and
, or
and not
have much lower precedence than &&
, ||
and !
and
and or
have the same precedence, while &&
has higher precedence than ||
In general, it is good style to avoid the use of and
, or
and not
and use &&
, ||
and !
instead. (The Rails core developers, for example, reject patches which use the keyword forms instead of the operator forms.)
The reason why they exist at all, is not for boolean formulae but for control flow. They made their way into Ruby via Perl's well-known do_this or do_that
idiom, where do_this
returns false
or nil
if there is an error and only then is do_that
executed instead. (Analogous, there is also the do_this and then_do_that
idiom.)
Examples:
download_file_via_fast_connection or download_via_slow_connection
download_latest_currency_rates and store_them_in_the_cache
Sometimes, this can make control flow a little bit more fluent than using if
or unless
.
It's easy to see why in this case the operators have the "wrong" (i.e. identical) precedence: they never show up together in the same expression anyway. And when they do show up together, you generally want them to be evaluated simply left-to-right.
and
/or
are for control flow.
Ruby will not allow this as valid syntax:
false || raise "Error"
However this is valid:
false or raise "Error"
You can make the first work, with ()
but using or
is the correct method.
false || (raise "Error")
puts false or true
--> prints: false
puts false || true
--> prints: true
The way I use these operators:
||, &&
are for boolean logic. or, and
are for control flow. E.g.
do_smth if may_be || may_be
-- we evaluate the condition here
do_smth or do_smth_else
-- we define the workflow, which is equivalent to
do_smth_else unless do_smth
to give a simple example:
> puts "a" && "b"
b
> puts 'a' and 'b'
a
A well-known idiom in Rails is render and return
. It's a shortcut for saying return if render
, while render && return
won't work. See "Avoiding Double Render Errors" in the Rails documentation for more information.
or
is NOT the same as ||
. Use only ||
operator instead of the or
operator.
Here are some reasons. The:
or
operator has a lower precedence than ||
.or
has a lower precedence than the =
assignment operator.and
and or
have the same precedence, while &&
has a higher precedence than ||
.Both or
and ||
evaluate to true if either operand is true. They evaluate their second operand only if the first is false.
As with and
, the only difference between or
and ||
is their precedence.
Just to make life interesting, and
and or
have the same precedence, while &&
has a higher precedence than ||
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With