design - ¿Cuántos parámetros son demasiados?
parameters language-agnostic (30)
Las rutinas pueden tener parámetros, eso no es noticia. Puede definir tantos parámetros como necesite, pero muchos de ellos harán que su rutina sea difícil de entender y mantener.
Por supuesto, puede usar una variable estructurada como solución alternativa: colocar todas esas variables en una sola estructura y pasarlas a la rutina. De hecho, usar estructuras para simplificar las listas de parámetros es una de las técnicas descritas por Steve McConnell en Code Complete . Pero como él dice:
Los programadores cuidadosos evitan agrupar los datos más de lo que es lógicamente necesario.
Entonces, si su rutina tiene demasiados parámetros o si usa una estructura para disfrazar una gran lista de parámetros, probablemente esté haciendo algo mal. Es decir, no estás manteniendo el acoplamiento suelto.
Mi pregunta es, ¿ cuándo puedo considerar que una lista de parámetros es demasiado grande? Creo que más de 5 parámetros, son demasiados. ¿Qué piensas?
¿Cuándo se considera algo tan obsceno como algo que se puede regular a pesar de la garantía de la 1ª Enmienda a la libertad de expresión? Según el juez Potter Stewart, "lo sé cuando lo veo". Lo mismo vale aquí.
Odio hacer reglas rápidas y duras como esta porque la respuesta cambia no solo en función del tamaño y el alcance de su proyecto, sino que también cambia hasta el nivel del módulo. Dependiendo de lo que esté haciendo su método, o de lo que se supone que representa la clase, es muy posible que 2 argumentos sean demasiados y sea un síntoma de demasiado acoplamiento.
Yo sugeriría que al hacer la pregunta en primer lugar y calificar su pregunta tanto como usted lo hizo, realmente sepa todo esto. La mejor solución aquí no es confiar en un número duro y rápido, sino buscar revisiones de diseño y revisiones de código entre sus pares para identificar áreas en las que tiene baja cohesión y acoplamiento apretado.
Nunca tengas miedo de mostrar a tus colegas tu trabajo. Si tiene miedo de hacerlo, esa es probablemente la señal más grande de que algo está mal con su código y que ya lo sabe .
Algún código con el que trabajé en el pasado usaba variables globales solo para evitar pasar demasiados parámetros.
Por favor no hagas eso!
(Generalmente.)
Basaría mi respuesta en la frecuencia con la que se llama la función.
Si es una función de inicio que solo se llama una vez, deje que tome 10 parms o más, a quién le importa.
Si se llama un montón de veces por fotograma, tiendo a hacer una estructura y solo le paso un puntero, ya que suele ser más rápido (suponiendo que no esté reconstruyendo la estructura cada vez).
Depende en gran medida del entorno en el que esté trabajando. Tome, por ejemplo, javascript. En javascript, la mejor forma de pasar parámetros es usar objetos con pares clave / valor, lo que en la práctica significa que solo tienes un parámetro. En otros sistemas el punto dulce será a las tres o cuatro.
Al final, todo se reduce a los gustos personales.
Dibujaría el límite para funciones públicas a 5 parámetros yo mismo.
En mi humilde opinión, las listas largas de parámetros solo son aceptables en las funciones de ayuda privadas / locales que solo deben llamarse desde algunos lugares específicos en el código. En esos casos, es posible que deba pasar una gran cantidad de información de estado, pero la legibilidad no es tan importante, ya que solo usted (o alguien que mantendrá su código y debería entender los aspectos fundamentales de su módulo) debe preocuparse por llamando a esa función.
En Clean Code , Robert C. Martin dedicó cuatro páginas al tema. Aquí está la esencia:
El número ideal de argumentos para una función es cero (niladic). Luego viene uno (monádico), seguido de cerca por dos (diádico). Deben evitarse tres argumentos (triádicos) cuando sea posible. Más de tres (políada) requiere una justificación muy especial y, por lo tanto, no debe usarse de ninguna manera.
En los peores 5 fragmentos de código , marque el segundo, "¿Es este un constructor?". Tiene como más de 37 ⋅ 4 ≈ 150 parámetros:
Aquí un programador escribió este constructor [... S] muchos de ustedes pueden pensar que sí, es un gran constructor, pero usó herramientas de generación automática de código Eclipse [.] NOO, en este constructor había un pequeño error que descubrí, lo que me hizo Concluyo que este constructor fue escrito a mano. (Por cierto, esto es solo la parte superior del constructor, no está completo).
En mi opinión, podría haber casos en los que exceda 4 o algún número fijo. Las cosas a tener en cuenta podrían ser
- Tu método está haciendo demasiado y necesitas refactorizar.
- Es posible que desee considerar el uso de una colección o alguna estructura de datos.
- Reconsidere el diseño de su clase, tal vez algunas cosas no necesitan ser transmitidas.
Desde el ángulo de la facilidad de uso o la facilidad de lectura del código, creo que cuando necesita "encajar" su firma de método, debería hacer que se detenga y piense, a menos que se sienta impotente y todos los esfuerzos para reducir la firma sean una ventaja. sin resultados. Algunas bibliotecas muy buenas en el pasado y el presente utilizan más de 4-5 cochecitos.
Es un hecho conocido que, en promedio, las personas pueden mantener 7 +/- 2 cosas en su cabeza a la vez. Me gusta usar ese principio con parámetros. Suponiendo que los programadores son personas inteligentes por encima de la media, diría que todo 10+ es demasiado.
Por cierto, si los parámetros son similares de alguna manera, los pondría en un vector o lista en lugar de una estructura o clase.
Esta respuesta asume un lenguaje OO. Si no está utilizando uno, omita esta respuesta (en otras palabras, no se trata de una respuesta independiente del lenguaje).
Si está pasando más de 3 o más parámetros (especialmente tipos / objetos intrínsecos), no es que sea "Demasiados" sino que es posible que no tenga la oportunidad de crear un nuevo objeto.
Busque grupos de parámetros que se pasan a más de un método; incluso un grupo que se pasa a dos métodos casi garantiza que debería tener un nuevo objeto allí.
Luego refactoriza la funcionalidad en su nuevo objeto y no creería cuánto ayuda tanto a su código como a su comprensión de la programación OO.
Estoy de acuerdo con que 3 está bien, 4 son demasiados como guía. Con más de 3 parámetros, inevitablemente estás haciendo más de una tarea. Más de una tarea debe dividirse en métodos separados.
Sin embargo, si miro el último proyecto en el que he trabajado, las excepciones abundarían y la mayoría de los casos sería difícil llegar a 3 parámetros.
Generalmente estoy de acuerdo con 5, sin embargo, si hay una situación en la que necesito más y es la forma más clara de resolver el problema, entonces usaría más.
Me detengo en tres parámetros como regla general. Un poco más y es el momento de pasar una matriz de parámetros o un objeto de configuración, lo que también permite agregar futuros parámetros sin cambiar la API.
Mi regla de oro es que necesito poder recordar los parámetros el tiempo suficiente para mirar una llamada y decir qué hace. Entonces, si no puedo ver el método y luego pasar a una llamada de un método y recordar qué parámetro hace qué, entonces hay demasiados.
Para mí eso equivale a unos 5, pero no soy tan brillante. Su experiencia puede ser diferente.
Puede crear un objeto con propiedades para mantener los parámetros y pasarlo si supera el límite establecido. Consulte el libro Refactoring Martin Fowler y el capítulo sobre cómo simplificar las llamadas a métodos.
Muchas gracias por todas sus respuestas:
Fue un poco sorprendente encontrar personas que también piensan (como yo) que 5 parámetros es un buen límite para la cordura del código.
En general, las personas tienden a estar de acuerdo en que un límite entre 3 y 4 es una buena regla general. Esto es razonable ya que las personas generalmente tienen un mal momento para contar más de 4 cosas.
Como señala Milán , en promedio las personas pueden tener más o menos 7 cosas en la cabeza a la vez. Pero creo que no puedes olvidar que, cuando estás diseñando / manteniendo / estudiando una rutina, debes tener en cuenta más cosas que solo los parámetros.
Algunas personas consideran que una rutina debe tener tantos argumentos como sea necesario. Estoy de acuerdo, pero solo para unos pocos casos específicos (llamadas a API de sistemas operativos, rutinas donde la optimización es importante, etc.). Sugiero ocultar la complejidad de estas rutinas agregando una capa de abstracción justo encima de estas llamadas siempre que sea posible.
Nick tiene algunos pensamientos interesantes sobre esto. Si no quieres leer sus comentarios, te resumo: en pocas palabras, depende :
Odio hacer reglas rápidas y duras como esta porque la respuesta cambia no solo en función del tamaño y el alcance de su proyecto, sino que también cambia hasta el nivel del módulo. Dependiendo de lo que esté haciendo su método, o de lo que se supone que representa la clase, es muy posible que 2 argumentos sean demasiados y sea un síntoma de demasiado acoplamiento.
La moraleja aquí es que no tenga miedo de mostrar su código a sus compañeros, discuta con ellos e intente "identificar áreas en las que tiene baja cohesión y acoplamiento estrecho" .
Finalmente, creo que Wnoise está muy de acuerdo con Nick, y concluye su contribución satírica con esta visión poética (ver comentarios más abajo) del arte de la programación:
La programación no es ingeniería. La organización del código es un arte porque depende de factores humanos, que dependen demasiado del contexto para cualquier regla dura.
Para mí, cuando la lista cruza una línea en mi IDE, es un parámetro demasiado. Quiero ver todos los parámetros en una línea sin interrumpir el contacto visual. Pero eso es solo mi preferencia personal.
Parece que hay otras consideraciones además del mero número, aquí hay algunas que vienen a la mente:
Relación lógica con el propósito principal de la función frente a la configuración única
Si solo son indicadores de entorno, la agrupación puede ser muy útil.
Según Perl Best Practices , 3 está bien, 4 es demasiado. Es solo una guía, pero en nuestra tienda eso es lo que intentamos mantener.
Según Jeff Bezos de la fama de Amazon, no se puede comer más de dos pizzas :
Según Steve McConnell en Code Complete , deberías
Limita el número de parámetros de una rutina a unos siete
Si empiezas a tener que contar mentalmente los parámetros en la firma y hacerlos coincidir con la llamada, ¡es hora de refactorizar!
Si tengo de 7 a 10 parámetros en una rutina, veo agruparlos en una nueva clase, pero no si esa clase no sería más que un montón de campos con captadores y definidores. La nueva clase tiene que hacer algo más que mezclar valores en y afuera. De lo contrario prefiero aguantar la larga lista de parámetros.
Siete cosas en la memoria a corto plazo?
- Nombre de la función
- Valor de retorno de la función.
- Finalidad de la función.
- Parámetro 1
- Parámetro 2
- Parámetro 3
- Parámetro 4
Una cosa que destacaría desde una perspectiva de rendimiento es que, dependiendo de cómo pase los parámetros a un método, pasar muchos parámetros por valor ralentizará el programa porque cada parámetro debe copiarse y luego colocarse en la pila.
¡Usar una sola clase para abarcar todos los parámetros funcionaría mejor porque un solo parámetro que se pasa por referencia sería elegante, más limpio y más rápido!
Una función solo puede tener demasiados parámetros si algunos de los parámetros son redundantes. Si se utilizan todos los parámetros, la función debe tener el número correcto de parámetros. Tome esta función de uso frecuente:
HWND CreateWindowEx
(
DWORD dwExStyle,
LPCTSTR lpClassName,
LPCTSTR lpWindowName,
DWORD dwStyle,
int x,
int y,
int nWidth,
int nHeight,
HWND hWndParent,
HMENU hMenu,
HINSTANCE hInstance,
LPVOID lpParam
);
Eso es 12 parámetros (9 si agrupas las x, y, w y h como un rectángulo) y también están los parámetros derivados del nombre de la clase. ¿Cómo reducirías esto? ¿Te gustaría reducir el número más al punto?
No deje que la cantidad de parámetros lo moleste, solo asegúrese de que sea lógico y esté bien documentado y deje que intellisense * lo ayude.
* ¡ Otros asistentes de codificación están disponibles!
Una pregunta relacionada que debe considerar es qué tan cohesive la rutina. Un gran número de parámetros puede ser un olor que te dice que la rutina en sí está tratando de hacer demasiado y por lo tanto su cohesión es sospechosa. Estoy de acuerdo en que un número de parámetros duro y rápido es probablemente imposible, pero supongo que una rutina de alta cohesión implicaría un bajo número de parámetros.
Una restricción de longitud en una lista de parámetros es solo una restricción más. Y la restricción significa violencia aplicada. Suena divertido, pero puedes ser no violento incluso cuando programas. Solo deja que el código dicte las reglas. Es obvio que si tiene muchos parámetros, el cuerpo de la función / método de clase será lo suficientemente grande como para hacer uso de ellos. Y los fragmentos de código grandes generalmente se pueden refactorizar y dividir en partes más pequeñas. Así que obtienes una solución contra tener muchos parámetros como bonificación gratuita, ya que se dividen entre las piezas de código refactorizadas más pequeñas.
Uno de los epigramas de programación más conocidos de Alan Perlis (que se cuenta en ACM SIGPLAN Avisos 17 (9), septiembre de 1982) dice que "si tiene un procedimiento con 10 parámetros, probablemente se haya perdido alguno".
Uno más de lo necesario. No me refiero a ser simplista, pero hay algunas funciones que necesariamente necesitan bastantes opciones. Por ejemplo:
void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);
Hay 6 argumentos, y cada uno de ellos es esencial. Además, no existe un vínculo común entre ellos para justificar el agrupamiento. Tal vez podrías definir "struct mmapargs", pero eso sería peor.
Algo menos y pierdes flexibilidad.