ruby-on-rails - objetos - proc ruby

do... end vs llaves para bloques en Ruby

Question

Tengo un compañero de trabajo que está tratando activamente de convencerme de que no debería usar do..end y en su lugar usar llaves para definir bloqueos multilínea en Ruby.

Estoy firmemente en el campo de usar solo llaves para frases cortas y hacer ... para todo lo demás. Pero pensé que me acercaría a la gran comunidad para obtener una resolución.

Entonces, ¿cuál es y por qué? (Ejemplo de algún código de shoulda)

context do
  setup { do_some_setup() }
  should "do somthing" do
    # some more code...
  end
end

o

context {
  setup { do_some_setup() }
  should("do somthing") {
    # some more code...
  }
}

Personalmente, solo mirando las respuestas anteriores, la pregunta para mí, pero quería abrir esto a la comunidad en general.

Answer 1

Estoy votando por do / end

La convención es do .. end para multiline y { ... } para one-liners.

Pero me gusta do .. end mejor, así que cuando tengo un trazador de líneas, uso do .. end todos modos, pero formatealo como siempre para do / end en tres líneas. Esto hace que todos estén felices.

  10.times do 
    puts ...
  end

Un problema con { } es que es poesía-modo-hostil (porque se unen estrechamente al último parámetro y no a toda la llamada al método, por lo que debe incluir el método parens) y simplemente, en mi opinión, no se ven tan bonito. No son grupos de declaraciones y chocan con las constantes de hash para la legibilidad.

Además, he visto suficientes { } en programas C. El camino de Ruby, como de costumbre, es mejor. Hay exactamente un tipo de bloque if , y nunca tiene que volver atrás y convertir una declaración en una sentencia compuesta.

Answer 2

Desde la programación de Ruby :

Las llaves tienen una alta precedencia; do tiene una baja precedencia. Si la invocación del método tiene parámetros que no están entre paréntesis, la forma de llave de un bloque se vinculará al último parámetro, no a la invocación general. El formulario do se vinculará a la invocación.

Entonces el código

f param {do_something()}

Vincula el bloque a la variable param mientras que el código

f param do do_something() end

Vincula el bloque a la función f .

Sin embargo, esto no es un problema si encierra los argumentos de función entre paréntesis.

Answer 3

En realidad, es una preferencia personal, pero una vez dicho esto, durante los últimos 3 años de mi ruby ​​experimenté lo que aprendí es que el rubí tiene su estilo.

Un ejemplo sería, si vienes de un fondo JAVA, para un método booleano que podrías usar

def isExpired
  #some code
end 

observe el caso camel y, a menudo, el prefijo ''es'' para identificarlo como un método booleano.

Pero en el mundo ruby, el mismo método sería

def expired?
  #code
end

así que personalmente pienso, es mejor ir con ''ruby way'' (Pero sé que toma un tiempo para que uno lo entienda (me tomó alrededor de 1 año: D)).

Finalmente, iría con

do 
  #code
end

bloques.

Answer 4

Hay algunos puntos de vista sobre esto, es realmente una cuestión de preferencia personal. Muchos rubyistas toman el enfoque que tú haces. Sin embargo, otros dos estilos que son comunes es usar siempre uno u otro, o usar {} para bloques que devuelven valores, y do ... end para bloques que se ejecutan para efectos secundarios.

Answer 5

Hay un beneficio importante para las llaves: muchos editores tienen MUCHO más fácil tiempo de igualarlas, lo que hace que ciertos tipos de depuración sean mucho más fáciles. Mientras tanto, la palabra clave "do ... end" es bastante difícil de igualar, especialmente porque "end" s también coincide con "if" s.

Answer 6

Hay una sutil diferencia entre ellos, pero {} se une más que do / end.

Answer 7

Hay una tercera opción: escribir un preprocesador para inferir "fin" en su propia línea, a partir de la sangría. Los pensadores profundos que prefieren el código conciso tienen razón.

Mejor aún, piratear ruby, así que esta es una bandera.

Por supuesto, la solución más simple de "elige tus peleas" es adoptar la convención de estilo de que una secuencia de finales aparece en la misma línea, y enseña el color de tu sintaxis para silenciarlos. Para facilitar la edición, se podrían usar scripts de editor para expandir / colapsar estas secuencias.

El 20% al 25% de mis líneas de código ruby ​​son "finales" en su propia línea, todas inferidas trivialmente por mis convenciones de sangría. Ruby es el lenguaje de ceceo para haber logrado el mayor éxito. Cuando la gente discute esto, preguntando dónde están todos los espantosos paréntesis, les muestro una función de rubí que termina en siete líneas de "fin" superfluo.

Codifiqué durante años usando un preprocesador de lisp para inferir la mayoría de los paréntesis: una barra ''|'' abrió un grupo que se cerró automáticamente al final de la línea, y un signo de dólar ''$'' sirvió como un marcador de posición vacío donde de otro modo no habría símbolos para ayudar a inferir las agrupaciones. Esto es, por supuesto, territorio de guerra religiosa. Lisp / esquema sin los paréntesis es el más poético de todos los idiomas. Aún así, es más fácil simplemente silenciar paréntesis usando coloreado de sintaxis.

Sigo codificando con un preprocesador para Haskell, para agregar heredocs y para poner por defecto todas las líneas enrasadas como comentarios, todo sangrado como código. No me gustan los personajes de comentarios, sea cual sea el idioma.

Answer 8

La convención general es usar do ... end para bloques multilineales y llaves para bloques de una sola línea, pero también hay una diferencia entre los dos que se puede ilustrar con este ejemplo:

puts [1,2,3].map{ |k| k+1 }
2
3
4
=> nil
puts [1,2,3].map do |k| k+1; end
#<Enumerator:0x0000010a06d140>
=> nil

Esto significa que {} tiene una precedencia más alta que do .. end, así que tenlo en cuenta cuando decidas qué quieres usar.

PD: un ejemplo más a tener en cuenta mientras desarrollas tus preferencias.

El siguiente código:

task :rake => pre_rake_task do
  something
end

realmente significa:

task(:rake => pre_rake_task){ something }

Y este código:

task :rake => pre_rake_task {
  something
}

realmente significa:

task :rake => (pre_rake_task { something })

Para obtener la definición real que desea, con llaves, debe hacer:

task(:rake => pre_rake_task) {
  something
}

Tal vez el uso de llaves para los parámetros sea algo que quieras hacer de todos modos, pero si no lo haces, probablemente sea mejor usar do ... fin en estos casos para evitar esta confusión.

Answer 9

La regla más común que he visto (más recientemente en Eloquent Ruby ) es:

• Si se trata de un bloque de varias líneas, utilice do / end
• Si se trata de un solo bloque de línea, usa {}

Answer 10

Mi estilo personal es enfatizar la legibilidad sobre las reglas rígidas de { ... } vs do ... end choice, cuando tal elección es posible. Mi idea de legibilidad es la siguiente:

[ 1, 2, 3 ].map { |e| e + 1 }      # preferred
[ 1, 2, 3 ].map do |e| e + 1 end   # acceptable

[ 1, 2, 3 ].each_with_object [] do |e, o| o << e + 1 end # preferred, reads like a sentence
[ 1, 2, 3 ].each_with_object( [] ) { |e, o| o << e + 1 } # parens make it less readable

Foo = Module.new do     # preferred for a multiline block, other things being equal
  include Comparable
end

Foo = Module.new {      # less preferred
  include Comparable
}

Foo = Module.new { include Comparable }      # preferred for a oneliner
Foo = module.new do include Comparable end   # imo less readable for a oneliner

[ [ 1 ], [ 1, 2 ] ].map { |e| e.map do |e| e + 1 end }  # slightly better
[ [ 1 ], [ 1, 2 ] ].map { |e| e.map { |e| e + 1 } }     # slightly worse

En una sintaxis más compleja, como bloques anidados multilínea, trato de intercalar { ... } y do ... delimitadores end para el resultado más natural, por ej.

Foo = Module.new { 
  if true then
    Bar = Module.new {                          # I intersperse {} and keyword delimiters
      def quux
        "quux".tap do |string|                  # I choose not to intersperse here, because
          puts "(#{string.size} characters)"    # for multiline tap, do ... end in this
        end                                     # case still loks more readable to me.
      end
    }
  end
}

Aunque la falta de reglas rígidas puede producir elecciones ligeramente diferentes para los diferentes programadores, creo que la optimización caso por caso para la legibilidad, aunque subjetiva, es una ganancia neta sobre la adherencia a las reglas rígidas.

Answer 11

Puse otra Respuesta, aunque ya se señaló la gran diferencia (prcedence / binding), y eso puede causar problemas difíciles de encontrar (Tin Man y otros lo señalaron). Creo que mi ejemplo muestra el problema con un fragmento de código no tan habitual, incluso los programas experimentados no se leen como los domingos:

module I18n
    extend Module.new {
        old_translate=I18n.method(:translate)
        define_method(:translate) do |*args|
            InplaceTrans.translate(old_translate, *args)
        end
        alias :t :translate
    }
end

module InplaceTrans
    extend Module.new {
        def translate(old_translate, *args)
            Translator.new.translate(old_translate, *args)
        end
    }
end

Luego hice un código que embellece ...

#this code is wrong!
#just made it ''better looking''
module I18n
    extend Module.new do
        old_translate=I18n.method(:translate)
        define_method(:translate) do |*args|
            InplaceTrans.translate(old_translate, *args)
        end
        alias :t :translate
    end
end

si cambias {} aquí para do/end obtendrás el error, ese método de translate no existe ...

Por qué sucede esto se señala aquí más de uno: precedencia. ¿Pero dónde poner llaves aquí? (@the Tin Man: siempre uso llaves, como tú, pero aquí ... supervisado)

así que cada respuesta como

If it''s a multi-line block, use do/end
If it''s a single line block, use {}

es simplemente incorrecto si se usa sin el "PERO ¡Tenga cuidado con las llaves / prioridad!"

de nuevo:

extend Module.new {} evolves to extend(Module.new {})

y

extend Module.new do/end evolves to extend(Module.new) do/end

(lo que sea, el resultado de extender lo hace con el bloque ...)

Entonces, si quieres usar do / end usa esto:

#this code is ok!
#just made it ''better looking''?
module I18n
    extend(Module.new do 
        old_translate=I18n.method(:translate)
        define_method(:translate) do |*args|
            InplaceTrans.translate(old_translate, *args)
        end
        alias :t :translate
    end)
end

Answer 12

Se reduce al sesgo personal, prefiero las llaves en un bloque do / end, ya que es más comprensible para un mayor número de desarrolladores debido a que la mayoría de los lenguajes de fondo los usan sobre la convención do / end. Con eso se dice que la verdadera clave es llegar a un acuerdo dentro de su tienda, si do / end es utilizado por 6/10 desarrolladores de CADA UNO debería usarlos, si 6/10 usa llaves, entonces apegue a ese paradigma.

Se trata de hacer un patrón para que el equipo en su conjunto pueda identificar las estructuras de código más rápido.

Answer 13

Un par de rubyists influyentes sugieren usar llaves cuando usas el valor de retorno, y do / end cuando no lo haces.

http://talklikeaduck.denhaven2.com/2007/10/02/ruby-blocks-do-or-brace (en archive.org)

http://onestepback.org/index.cgi/Tech/Ruby/BraceVsDoEnd.rdoc (en archive.org)

Esto parece una buena práctica en general.

Modificaría un poco este principio para decir que debes evitar usar do / end en una sola línea porque es más difícil de leer.

Debes tener más cuidado al utilizar llaves porque se unirá al parámetro final de un método en lugar de a la llamada al método completo. Simplemente agregue paréntesis para evitar eso.