2011-09-17 9 views

Respuesta

1

que tendría que escanear fuente para encontrar el "más común".

Trato de escribir lo que tiene sentido, dadas las circunstancias, pero utilizaría casi siempre ya sea:

func_a func_b(arg) 
func_a(func_b(arg)) 

Si las funciones se nombran las cosas que "suena como" una oración o frase, entonces voy a caer tantos parens como pueda.

func_a func_b arg 

En otras palabras, si suena como algo que diría en voz alta, voy a escribir como yo diría que - una oración o frase.

Si no suena como algo que diría en la vida real, necesita paréntesis para mejorar la claridad, etc. entonces lo escribiré como si estuviera escribiendo código, porque suena/parece código.

2

no te la puedo dar la forma más común, pero mi opinión personal.

Rechazaría la versión uno func_a func_b input. Es muy confuso, no se ve si input es el parámetro de func_b, o si es el 2º parámetro de func_a.

Prefiero la versión cuatro, se muestra explícita, ¿cuál es el parámetro para qué (y verá, qué es un método y qué es una variable). Pero me gustaría añadir espacios antes y después del paréntesis:

func_a(func_b(input)) 

o

func_a(func_b(input)) 
+4

Ew; Nunca he entendido espacios después de abrir/antes de cerrar parens. –

+0

Acepto que 'func_a func_b input' es confuso, pero técnicamente no es ambiguo. Como Ruby no tiene currying, 'input' definitivamente no es un segundo parámetro de' func_a' (que sería 'func_a func_b, input'). Sin embargo, el hecho de que toda la comprensión de la línea depende de la presencia/ausencia de un personaje pequeño (una coma), parece una mala práctica. – rubergly

+0

@Dave No intente aprender ABAP, allí los espacios son necesarios. En mi caso: después de algunos años con ABAP, estoy acostumbrado a hacerlo y cuando leo código, mi cerebro puede analizar más fácilmente el código con espacios. Creo que es un hábito confirmado para mí. – knut

Cuestiones relacionadas