2008-12-04 10 views

Respuesta

8

Supongo que hago las dos cosas, pero definitivamente las guardo si esto aumenta la legibilidad y evita afirmaciones que parecen ambiguas.

3

Cualquiera que sea más legible por lo general.

Pero siempre usar paréntesis cuando estoy función de anidación llama dentro de los parámetros de otros queridos

6

Si se refiere a las llamadas de función, siempre pongo entre paréntesis porque siempre es más fácil de leer. Si quieres decir en condiciones (si, mientras) solo pongo paréntesis cuando son necesarios.

+1

Estoy de acuerdo. En php, por ejemplo, puedo detectar rápidamente una var por el prefijo $. En javascript puedo reconfigurar una función por el paréntesis(). En Ruby, la diferencia entre var o func (sin paréntesis) no siempre es fácil de ver. –

7

Intento dejarlos fuera, si es posible. Creo que hace que el código sea más fácil de leer (en términos generales).

9

Los dejo cuando estoy haciendo cosas DSL-ish, como t.column o has_many en rieles. El resto del tiempo, generalmente se reduce a la claridad, y es probable que sea una división pareja.

82

Desde el Elements of Ruby Style

Rubí le permite dejar de lado entre paréntesis, en general, resistir esta tentación .

Los paréntesis hacen que el código sea más fácil para seguir. Rubí estilo general es utilizar ellos, excepto en los siguientes casos:

  • siempre dejan fuera paréntesis vacíos
  • Los paréntesis pueden eliminarse de un solo comando que está rodeado por ERb delimitadores - ERB los marcadores hacen que asegure que el código todavía es legible
  • Una línea que es un solo comando y un único argumento simple puede ser escrita sin paréntesis. Personalmente, me parece que hago esto menos y menos, pero todavía es perfectamente legible. Tiendo a no gustarme las líneas simples en código ruby ​​regular que tienen argumentos múltiples y sin paréntesis.
  • Muchos lenguajes específicos de dominio basados ​​en Ruby (como Rake) no usan el paréntesis para conservar un lenguaje más natural en sus declaraciones.
2

Tiendo a dejarlos fuera cuando hago aserciones como assert_equal. Tal vez es para hacerlo como un lenguaje específico del dominio.

22

utilizo como parens comentarios para ayudar al futuro mí ... que es probable que tenga menos células que la corriente me :-)

Nada peor que buscar en algún código que escribió hace 2 años y malentendidos esto, para que rompas algo mientras lo modificas.

Si los pares me ahorrarán unos minutos (u horas) en el futuro, incluiré todos los que sean necesarios para que la declaración sea clara.

- John

+1

+1 "Uso parens como comentarios para ayudar al futuro yo ... que es probable que tenga menos células cerebrales que el yo actual :-)" Eso es TAN verdadero, y exactamente por qué lo hago. También es misericordioso para cualquier persona que me siga y deba usar mi código. En resumen, es algo de mantenimiento. –

2

Si usted ha estado programando desde hace mucho tiempo, es probable que tenga una "comezón" para añadir paréntesis, y en muchos casos hay buenas razones para ello.

El código es más fácil para los ojos, aunque en mi opinión, y no he tenido ningún problema todavía - si va a necesitar paréntesis, lo sabrá de antemano antes de que tenga que toparse con el Script de depuración.

+3

"Mi maestro me dice que es inevitable". Es, y puede ser difícil de depurar. Recomiendo usarlos para evitar la asignación ambigua de parámetros. –

+0

Downvoted como "más fácil para los ojos" es IMO una razón pésima para dejar fuera paréntesis alrededor de los argumentos de la función. –

+0

hablando con la multitud no parens me encontré con este problema el otro día 'si owner.is_a? cosa // funcionó bien' 'if owner.is_a? cosa && x> 1 // no está bien' solo he estado aprendiendo ruby ​​por un par de semanas y donde trabajo usa la menor cantidad de caracteres posible y si vienes de cualquier otro idioma, hay una curva de aprendizaje para saber cuando pasas un hash implícitamente, una serie de símbolos, pasando a símbolos para una función ... no soy fanático. –

Cuestiones relacionadas