¿Es una mala idea enumerar cada argumento de función / método en una nueva línea y por qué?

Trabajo con alguien que, cada vez que llaman a una función, ponen los argumentos en una nueva línea, por ejemplo

aFunction(
    byte1,
    short1,
    int1, 
    int2,
    int3,
    int4,
    int5
) ;

Esto me resulta muy molesto, ya que significa que el código no es muy compacto, por lo que tengo que escanear más y más para entender la lógica. Me interesa saber si esto es realmente una mala práctica y, de ser así, ¿cómo puedo convencerlos de que no lo hagan?

Es solo una guía de codificación que puede gustarle o no. Lo importante es que usted y sus colegas acuerden usarlo o no.

Obviamente, la mejor manera de aumentar la legibilidad es limitar el número de argumentos.

Es una cuestión de preferencia. Para llamadas a funciones complicadas donde desea documentar cada parámetro, o donde las variables son bastante largas y hay muchas, esto puede ser bueno.

Por ejemplo:

do_complex_op(
      0, //Starting state, always 0, ask Joe why
      X, //X-coord of thingy
      y, //Y-coord of thingy
      73, //in this case, we don't want to use Z but want constant 
      dlogMessageTitle, //message for dialogue title
      dlogMessageText, //message for dialogue contents, don't care about this.
      SomethingIP, //IP of something-or-other server, can be NULL, won't crash.
      someObject.childObject.getValue(key1).HVAL, //very long path to HVAL
      someObject.childObject.getValue(key1).LVAL, //very long path to LVAL
      this.parentWindow.owner.mainTextBox.text.value.trim, //get the trimmed text, untrimmed text causes weird output
      pvrMainSettingForLongBlahs.getObjectByPath(somePath),
      pvrMainSettingForLongBlahs.K_TCA_UPPER_LIMIT,
      pvrMainSettingForLongBlahs.K_ENDPOINT_COMPLIANCE_LEVEL,
 );

Con lenguajes que permiten parámetros con nombre, esto es más común si usa los nombres de los parámetros (el ejemplo está en PL / SQL):

PKG_SOME_TEST_CODE.FN_DO_SOMETHING( in_text => 'test text',
                                    in_id => v_id,
                                    in_ref_id => v_ref_id,
                                    out_array_for_storage => v_bArray); 

Pero estoy de acuerdo con usted en que si la llamada a la función es simple y no tiene demasiados parámetros, esto podría ser molesto, como por ejemplo:

setColour (
    r,
    g,
    b
 );

Me resulta mucho más fácil de leer como

 setColour(r,g,b);

Para @ammoQ:

rc=a(b,c(d,e(f)))

rc=a(
     b,
     c(
       d,
       e(
         f
        )
      )
    )

En mi opinión, todo lo que es poco común es una mala práctica, a menos que se pueda demostrar positivamente su superioridad sobre el estilo habitual. "La cuestión del gusto" es una excusa pobre para escribir código que es más difícil de leer de lo necesario para la mayoría de los programadores, porque un día, un alma pobre, no acostumbrada a ese estilo, tendrá que mantener ese código.

Probar que es poco común es relativamente fácil, muestre la fuente de ejemplos en MSDN o sitios similares, muestre grandes bases de código abierto, etc. Muestre la salida de los embellecedores de código. En última instancia, muestre cómo todos los demás en su equipo lo están haciendo. No aceptes un mal estilo solo porque alguien es demasiado terco.

Bueno, aquí hay un cebo de votos negativos. Nunca me han acusado de hacer lo popular. Claramente, si las cosas encajan en una línea, entonces bien, ajústelas en una línea.

Pero mi principal preocupación no es si el código es "feo" o "bonito". Mi principal preocupación es lo fácil que es comprender y realizar cambios sin cometer errores.

Si los argumentos son largos y hay muchos, ¿por qué no ponerlos en líneas separadas? En mi opinión, eso hace que sea más fácil ver qué son, y más fácil cambiarlos si es necesario. También me da espacio para adjuntar un comentario a cada argumento si lo deseo.

También quiero minimizar la posibilidad de cometer un error si agrego o elimino un argumento a una función, lo que es más probable que ocurra al final de una lista de argumentos que al principio. Por esa razón, prefiero poner la coma (,) al principio de una línea, que al final. Entonces, si, por ejemplo, quiero eliminar o agregar un argumento al final de la lista, es una edición de una línea. No tengo que jugar con la coma que debe ir al final de todas las líneas sino a la última, donde la última tiene que terminar con un paréntesis.

Entonces (chico, me van a echar por esto) lo escribo así:

nameOfFunction(firstArgument
    , secondArgument // optional comment
       ...
    , lastArgument   // optional comment
    );

Cuando hay una función con de cinco a veinte argumentos, la función no fue así de una vez. Creció con el tiempo, lo que significa que hubo muchas ediciones. Cualquier edición no completada es un error de sintaxis o un error. Así que no digo que esto sea bonito. Afirmo que ayuda a hacer las ediciones correctas.

(Y para aquellos que dicen que debería pasar una estructura en su lugar, todo lo que hace es desplazar el problema, porque necesita un montón de líneas de código para completar la estructura, sin mencionar el código adicional para declararlo y asignarlo).

Yo tampoco lo llamaría. La mejor práctica en la que he trabajado ha sido que las llamadas a funciones se realicen en una sola línea, a menos que tenga que desplazarse horizontalmente cualquier cantidad significativa para ver toda la llamada. Es una decisión, pero definitivamente diría que poner todas las funciones como esta está fuera de línea a menos que ese sea el estándar establecido por su organización.

Esta es la razón por la cual es una buena práctica para una organización establecer un conjunto de guías que todos los programadores deben cumplir. Se trata de consistencia y legibilidad.

Hace que sea más fácil:

• Reordenar argumentos.
• Comente o deshabilite los argumentos.
• Vea exactamente qué argumento ha cambiado cuando ve diferencias en su sistema de control de versiones
• Evite volver a sangrar y ajustar todo al agregar o quitar un argumento, o al cambiar el nombre de la función. (Incluso si su editor sangra automáticamente, todavía está creando muchos cambios de espacio en blanco inútiles que hacen que sea más difícil seguir los cambios en su sistema de control de versiones).

Yo diría que las llamadas a funciones deben estar todas en una línea a menos que excedan significativamente el ancho de código estándar (a menudo 80 caracteres, a menudo causa de argumentos :-).

No veo ninguna ventaja en este estilo. Se ve subjetivamente feo, y me resulta doloroso cuando busco código. Por ejemplo, es posible que desee buscar rápidamente y ver si alguna vez se llama a la función con un cierto parámetro pasado como NULL. Esto es fácil visualmente cuando todos los parámetros están en una línea, y más difícil cuando se dividen así.

Con frecuencia he visto ese estilo en declaraciones o definiciones de funciones , pero nunca en una llamada (hasta ahora). Allí tiene sentido a veces, ya que le permite agregar un comentario para parámetros individuales con mayor claridad. Parece que copió ese estilo a las llamadas sin saber realmente las razones subyacentes. Usted tiene un buen argumento en contra y él no parece tener uno bueno, así que tiene mi voto, pero no soy a quien tiene que convencer.

¿Va en contra de los estándares de codificación de la empresa?

Si no es así, inicie una discusión sobre los estándares y lo que a la gente le gustaría ver cambiada. Asegúrate de mencionar esto como una de las cosas que te gustaría cambiar.

Tenga una discusión completa sobre por qué no cree que esto sea útil y esperemos que gane el día. Nunca se sabe que su colega podría convencerlo de que su camino es el mejor después de todo;)

Una vez que tenga un estándar actualizado, se documenta lo que todos deberían codificar, por lo que si su colega persiste en hacerlo, puede mencionarlo en sus revisiones de código.

Puede parecer funky para ti, pero hace que trabajar en código sea más fácil. Mientras refactoriza, puede comentar argumentos individuales muy fácilmente y verificar su refactorización antes de eliminar cosas. También puede comentar y reemplazar temporalmente los tipos con bastante facilidad.

También es más fácil de leer que:

int f(int, int, int,
      char, double, int
      X const&, Y)
{}

No me he vuelto tan extremo como muestra (dado que no hay nombres en los parámetros, no es muy útil), pero me he acostumbrado a dividir cada parámetro en su propia línea o no dividirlo en absoluto.

La parte importante es que su código se puede imprimir o mostrar en pantallas estándar de 80col y seguir siendo legible.

Raramente obtendrá una respuesta honesta de un programador para algo como esto. Todos responderán con lo que hacen o no prefieren. La verdad es que, a pesar de que todos luchamos con ella a veces, la única "mala práctica" aquí es su propia inflexibilidad.

Tienes que ser brutalmente honesto contigo mismo para poder distinguir entre cosas que son realmente malas y cosas que simplemente te molestan. La verdad es que en C / C ++ y lenguajes similares rara vez encontrará una práctica de sangría que tenga un efecto tangible en la comprensión del código. La mayoría de las discusiones sobre este tipo de cosas solo tienen a ambas partes apiladas con personas que hacen argumentos ridículos y falsos para tratar de justificar su propia preferencia personal.

Lo que para mi lectura ... es exactamente lo que está solicitando en esta pregunta: un argumento ridículo y falso para justificar su preferencia personal.

Para ser honesto, depende de la persona. Diría que para funciones complejas como lo demuestra el primer ejemplo de FrustratedWithForms, luego sí; de lo contrario un gran NO. Por otra parte, esta es la razón por la que prefiero aplicar la funcionalidad IDE de código arbitrariamente.

"Me interesa saber si esto es realmente una mala práctica ..."

Sí, es una mala práctica, excepto cuando la lista de variables es anormalmente larga. Pero en ese caso, el problema probablemente se deba al diseño de la función. ¿Por qué no pasar un objeto que encapsula muchos de los parámetros?

"... y si es así, ¿cómo puedo persuadirlos para que no lo hagan?"

Átalos y hazles cosquillas hasta que acepten detener esa basura.

¿Por qué malgastas ciclos en una cuestión tan trivial? Simplemente inicie su IDE de confianza, abra el archivo y vuelva a formatear. Voila! Será en la forma que desee.

Ahora pasemos al tema realmente importante: vi o emacs, LOL.

Yo diría que si los argumentos encajan en una línea, hazlo. Si no, entonces un argumento por línea permite una gran legibilidad.

foo(arg1, arg2, arg3, arg4, arg5)

vs.

foo(
    arg1=arg1,
    arg2=arg2,
    arg3=arg3,
    arg4=arg4,
    arg5=arg5,
    arg6=arg6,
    arg7=arg7
)