Diferencia entre "o" y || en Ruby?

Como los otros ya han explicado, la solo diferencia es la precedencia. Sin embargo, me gustaría señalar que en realidad hay dos diferencias entre los dos:{[30]]}

1. and, or y not tienen mucho menor precedencia que &&, || y !
2. and y or tienen la misma precedencia , mientras que && tiene mayor precedencia que ||

En general, es un buen estilo para evitar la uso de and, or y not y uso &&, || y ! en su lugar. (Los desarrolladores del núcleo de Rails, por ejemplo, rechazan los parches que usan las formas de palabra clave en lugar de los formularios de operador.)

La razón por la que existen en absoluto, no es para fórmulas booleanas, sino para el flujo de control. Se abrieron camino hacia Ruby a través del conocido modismo de Perl do_this or do_that, donde do_this devuelve false o nil si hay un error y solo entonces se ejecuta do_that en su lugar. (Analogous, there is also the do_this and then_do_that modismo.)

Ejemplos:

download_file_via_fast_connection or download_via_slow_connection
download_latest_currency_rates and store_them_in_the_cache

A veces, esto puede hacer que el flujo de control sea un poco más fluido que usar if o unless.

Es fácil ver por qué en este caso los operadores tienen la precedencia "incorrecta" (es decir, idéntica): nunca aparecen juntos en la misma expresión de todos modos. Y cuando lo hacen aparecen juntos, generalmente quieren que sean evaluados simplemente de izquierda a derecha.

Y/o son para flujo de control.

Ruby no permitirá esto como sintaxis válida:

false || raise "Error"

Sin embargo esto es válido:

false or raise "Error"

Puedes hacer el primer trabajo, con () pero usar or es el método correcto.

false || (raise "Error")

puts false or true 

Impresiones: falso

puts false || true 

Impresiones: verdadero

Debes tener cuidado.

La forma en que uso estos operadores:

||, && son para la lógica booleana. or, and son para el flujo de control. Por ejemplo,

do_smth if may_be || may_be -- evaluamos la condición aquí

do_smth or do_smth_else -- definimos el flujo de trabajo, que es equivalente a do_smth_else unless do_smth

Para dar un ejemplo simple:

> puts "a" && "b" b

> puts 'a' and 'b' a

Un modismo bien conocido en Rails es render and return. Es un atajo para decir return if render, mientras que render && return no funcionará (ver documentación de Rails )

O NO es lo mismo que||

Utilice solo || operator en lugar de o operator.

Razones:

• o operador tienen menor precedencia que ||
• o tienen menor precedencia que = operador de asignación
• y y o tienen la misma prioridad, mientras que && tiene mayor prioridad que ||

Tanto "or" como "||" evalúan a true si cualquiera de los operando es true. Evalúan su segundo operando solo si el primero es falso.

Al igual que con "and", la única diferencia entre "or" y "||" es su precedencia.

Solo para hacer la vida interesante, "y" y "o" tienen la misma precedencia, mientras que "&&" tiene una precedencia más alta que "||".

Para añadir a la respuesta de mopoke, también es una cuestión de semántica. or se considera una buena práctica porque lee mucho mejor que ||.