¿Nombráis los argumentos en las llamadas a funciones?

[Negora]

Hola:

En lenguajes que no soportan el concepto de argumentos con nombre, cuando llamamos a una función (o a un método, en lenguajes tipo OO), podemos escribir directamente los valores que pasaremos a la llamada, o crear variables temporales que nombren qué representa cada valor. Esto último lo practica alguna gente bajo la filosofía del "self-documenting code".

Si optamos por escribir directamente los valores, esto nos obliga, o bien a memorizar qué argumentos recibe cada función y en qué orden, o bien a usar un IDE que nos los muestre. Es decir, que no se pueden leer en el propio código, lo que puede ser un problema si alguien con menos conocimiento accede al código fuente desde un terminal o un editor de textos. Otro problema es que si se anidan llamadas, hay que formatearlas muy bien para que sean legibles.

Si elegimos la otra opción, podemos ver claramente para qué es cada valor. Pero con el inconveniente de que hay mucho más texto que leer (según el lenguaje) y más "conexiones" que realizar mentalmente entre la llamada y la declaración de los argumentos.

Una tercera posibilidad es usar la segunda opción, pero hacer excepciones para métodos comunes y muy bien conocidos que se repiten mucho durante el código. Ejemplos: String.substring, String.indexOf, Math.abs, etc.

Así que quería saber qué hacéis en vuestro día a día. ¿Confiáis en vuestro IDE para estas cosas o preferís que el propio código fuente lo exprese?

Gracias.

[agleiva]

Empecemos por decir que si tus métodos / funciones tienen muchos argumentos de entrada (digamos más de 4 o 5) estas haciendo algo mal. Deberías meter todos esos datos sueltos en una clase o contenedor que los agrupe de alguna forma:

Ejemplo:

Código F#:

let actualizarDatos(nombreDelCliente: string, apellidoDelCliente: string, domicilioDelCliente: string, ....) = ....
 

Versus

Código F#:

let actualizarDatos(cliente: Cliente) = .....
 

Luego: yo personalmente uso named arguments SOLO cuando esos argumentos son opcionales. Si un metodo tiene un gran numero de argumentos opcionales, y vas a omitir algunos o muchos... los que SI estas especificando conviene aclarar cuales son.

Lo de IDE versus notepad: Usá las herramientas que corresponde. El notepad no es una herramienta para programar, Visual Studio si.

[Negora]

Hola agleiva:

En cuanto al número de argumentos, aunque antiguamente cometía ese error, hace ya algún tiempo que procuré reducir su número al menor posible. Pero está bien que lo comentes por si acaso.

Mi pregunta iba más encaminada a hacer el código legible en esos casos en los que se accede al código sin un IDE que te diga qué es cada argumento en esa llamada. O si se usa un IDE, para no tener que inspeccionar los nombres de esos argumentos en la firma del método, mientras se va leyendo la llamada. ¿Sería algo que descartarías totalmente en beneficio de hacer el código más conciso?

Gracias.

[Tachikomaia]

Cuando estaba aprendiendo funciones usar argumentos me pareció confuso o innecesario, y nunca lo he aprendido, así que no. Tampoco sé cual sería la ventaja de hacerlo.

[Negora]

Hola Tachikomaia:

Gracias por responder. Lo de poner nombres a los argumentos de una llamada se suele hacer para que el código sea más fácil de entender, incluso desde un terminal o un editor de textos, sin un IDE. O al menos eso es lo que recomiendan los que practican el llamado "self-documenting code".

Con todo esto yo tengo sentimientos enfrentados. Cuando la función (o método) que llamas no es muy conocida, lo de crear variables para nombrar los argumentos surge solo. Pero cuando se trata de funciones comunes, que se repiten durante todo el código, tiendo a poner los argumentos directamente, sin nombres. Porque al leerlos ya sé qué es cada argumento por su posición.

Pero claro, eso depende exclusivamente de MIS conocimientos. Si alguien editase mi código, seguramente no partiría de ese mismo conocimiento. Así que no sé dónde establecer ese "corte". ¿Sólo en las APIs más básicas del lenguaje? ¿O sólo en una serie de funciones establecidas de antemano para cada proyecto? Dudo de que haya una respuesta única, la verdad.

Saludos.