language-agnostic parameters

language agnostic - ¿Cuántos parámetros de función son demasiados?



language-agnostic parameters (15)

Bueno, seguramente dependerá de lo que esté haciendo su función en cuanto a cuántos se considerarían "demasiados". Una vez dicho esto, es posible tener una función con muchos parámetros diferentes que son opciones sobre cómo manejar ciertos casos dentro de la función, y tener sobrecargas a esas funciones con valores correctos por defecto para esas opciones.

Con la omnipresencia de Intellisense (o equivalente en otros IDEs) y los tooltips que muestran los comentarios de la Documentación XML en Visual Studio, realmente no creo que haya una respuesta firme a esta pregunta.

Posible duplicado:
¿Cuántos parámetros son demasiados?

Estaba escribiendo una función que incluía varios valores y me hizo pensar. ¿Cuándo es demasiada la cantidad de argumentos para una función / método? ¿Cuándo (si) señala un diseño defectuoso? ¿Diseñas / refactorizas la función para tomar estructuras, matrices, punteros, etc. para disminuir la cantidad de argumentos? ¿Refactoriza los datos que ingresan para disminuir la cantidad de argumentos? Sin embargo, parece que esto podría ser un poco menos aplicable en los diseños de OOP. Solo curiosidad por ver cómo otros ven el problema.

EDITAR: como referencia, la función que acabo de escribir tomó 5 parámetros. Utilizo la definición de varios que mi profesor AP Econ me dio. Más de 2; menos de 7.


Demasiado parámetro es un "Code Smell".

Puede dividir en varios métodos o usar la clase para reagrupar variables que tienen algo en común.

Poner un número para "Demasiado" es algo muy subjetivo y depende de tu organización y del idioma que uses. Una regla general es que si no puedes leer la firma de tu método y tienes una idea de qué es haciendo que podría tener demasiada información. Personnaly, trato de no pasar 5 parámetros.


Depende fuertemente de los tipos de argumentos. Si todos son enteros, 2 pueden ser demasiados. (¿Cómo recuerdo qué orden?) Si algún argumento acepta nulo, entonces el número cae drásticamente.

La verdadera respuesta viene de preguntarte:

  • ¿Qué tan fácil es entender las llamadas cuando estoy leyendo el código?
  • ¿Qué tan fácil es recordar los argumentos correctos y el orden de los argumentos al escribir el código?

Depende también de la función, si su función requiere una gran intervención del usuario o variables, no pasaría del rango 7-8. En cuanto a la cantidad promedio de parámetros, 5-6 es el punto óptimo en mi opinión. Si está utilizando más que eso, puede considerar objetos de clase como parámetros u otras funciones más pequeñas.


En general, creo que si los parámetros están funcionalmente relacionados (p. Ej., Coordenadas o componentes de color), deben encapsularse como una clase para buenas medidas.

No es que siempre siga esto yo mismo;)


No lo sé, pero lo sé cuando lo veo.


Para mí es 5.

Es difícil de manejar (recuerde nombre, orden, etc.) más allá de eso. Además, si llegué tan lejos, tengo versiones con valores predeterminados que llaman a este.


Respuesta rápida: cuando tienes que parar y hacer esa pregunta, tienes demasiadas.

Personalmente, me gusta mantener el número bajo seis. Si se necesita más, entonces la solución depende del problema. Un enfoque es usar funciones de "setter" para dar los valores a un objeto que eventualmente realizará la función que desee. Otra opción es usar una estructura, como mencionaste. De cualquier forma, no puedes equivocarte.


Robert C. Martin (Uncle Bob) recomienda 3 como máximo en Clean Code: Un manual de software ágil.

No tengo el libro en este momento, pero su razonamiento tiene que ver con una, dos y, en menor medida, con tres funciones de argumento que leen bien y que muestran claramente el propósito de la función.

Esto, por supuesto, va de la mano con su recomendación de funciones muy cortas y bien nombradas que se adhieren al Director de Responsabilidad Individual .


Según Steve McConnell en Code Complete , deberías

Limite el número de parámetros de una rutina a aproximadamente siete


Si tiene que preguntar, probablemente sean demasiados.


También he escuchado esa 7 figura, pero de alguna manera siento que proviene de un tiempo en el que todo lo que se podía pasar eran valores primitivos.

Hoy en día puede pasar una referencia a un objeto que encapsula algún estado complejo (y comportamiento). Usar 7 de ellos definitivamente sería demasiado.

Mi objetivo personal es evitar usar más de 4.


Varía de persona a persona. Personalmente, cuando tengo problemas para comprender inmediatamente qué hace una llamada de función leyendo la invocación en el código, es hora de refactorizar para quitar la tensión de mis celdas grises.


Y depende del lenguaje de programación ... En C, realmente no es raro ver funciones con 7 parámetros. Sin embargo, en C #, rara vez he visto más de 5 parámetros y personalmente uso menos de 3 por lo general.

// In C draw_dot(x, y, size, red, green, blue, alpha) // In C# Point point(x,y); Color color(red,green,blue,alpha); Tool.DrawDot(point, color);


Yo diría máximo 4. Cualquier cosa anterior, creo que debería colocarse dentro de una clase.