¿Qué tan grande debe ser la longitud de la función (líneas de código en una función)? [duplicar

Question

Posible duplicado:
¿Cuántas líneas de código debe tener una función/procedimiento/método?

¿Me gustaría saber cuántas líneas de código deberían tener funciones? Cuántas líneas es demasiado.

Leí esto hace un tiempo, alrededor de 10 o 20 líneas, pero fue porque la pantalla solo acomodaría muchas líneas. Ahora, a medida que el tamaño de la pantalla se hace más grande, eso no se mantendrá cierto.

Supongamos que la no parte de la función se usa en ningún otro lugar, es decir, ignora el principio seco.

Me gustaría escuchar lo que otros tienen que decir sobre esto.

Gracias.

Nota: Duplicado de ¿Cuándo es una función demasiado larga?, no pude encontrarlo cuando publiqué.

Answer 1

Este tipo de pregunta está bien respondida en Código completo. Steve McConnel escribió toda una página Para responder a esta pregunta. Su conclusión:

Décadas de evidencia dicen que las rutinas de tal longitud (> 100 líneas) no son más propensas a errores que las rutinas más cortas. Deje que problemas como la cohesión de la rutina, el número de puntos de decisión, el número de comentarios necesarios para explicar la rutina y otras consideraciones relacionadas con la complejidad dicten la duración de la rutina en lugar de imponer una restricción de longitud per se. Dicho esto, si desea escribir rutinas por más de 200 líneas, tenga cuidado.

Answer 2

Las líneas son irrelevantes, pero la complejidad lo es.

Una función debe hacer una tarea, y debe ser evidente. No debería llevarte más de unos momentos entender exactamente cómo y qué hace la función.

Answer 3

Debería tener tantas como necesite.

No veo ningún punto en restringir un conteo de línea de función al tamaño de la pantalla (está bien, para ser justo, no comencé a programar hasta después de que las pantallas pudieran acomodar más de 10-20 líneas, tal vez esto tenía sentido en algunos entornos) . Simplemente escriba la función como tiene sentido. Cuando sea tan grande que las piezas de código comiencen a repetirse, refactorice esas piezas a otras funciones/clases/componentes.

Answer 4

Es una regla general bastante arbitraria. A algunos les gustan las 20 líneas, a otras como la regla sin desplazamiento. Al final, solo asegúrese de que sea legible y fácil de entender de un vistazo. Lee sobre tu Principios sólidos y asegúrese de que el método tenga solo 1 responsabilidad, etc.

Answer 5

Mientras sea necesario, lo más corto posible.

Tomo 5-10 líneas como regla general, pero si hay alguna lógica que no se puede (re) factorizada fácilmente en múltiples funciones que escribo más tiempo cuando sea necesario. Por otro lado, a menudo tengo funciones que son solo una línea o dos de largo.

Si no lo hace inmediatamente Comprenda lo que hace una parte del código, escriba una nueva función para ello.

Answer 6

No creo que importe cuántas líneas tiene ... siempre que sea eficiente.

Cualquier código que se pueda reutilizar en cualquier lugar de su base de código debe moverse a otra función/método en la misma clase o una clase compartida y llamar.

Answer 7

He escuchado la métrica del tamaño de la pantalla antes, pero obviamente no pretendía ser un límite duro o escalar con el tamaño del monitor. Solo pretende transmitir el principio de seco y que mantener las funciones lo más pequeñas posible es una de las mejores formas de escribir código que puede escalar (en el tamaño del proyecto).

Answer 8

El documento de estilo de codificación de kernel de Linux dice:

Las funciones deben ser cortas y dulces, y hacer una sola cosa. Deben caber en uno o dos pantallas de texto (el tamaño de la pantalla ISO/ANSI es 80x24, como todos sabemos), y hacer una cosa y hacerlo bien.

Ahora, me doy cuenta de que esto está en el contexto del código del núcleo, pero creo que algunos de los puntos que hace de la longitud de la función son generalmente válidas. Encontrar una copia aquí. La sección de funciones es el Capítulo 4.

En general, la longitud de la función no debe estar limitada por alguna regla artificial; Facture las cosas si tiene sentido, y porque hace que las cosas sean más fáciles de leer, pero la regla de 1-2 pantallas no está escrita en piedra.

Answer 9

Esta es solo una opinión de una perspectiva OO:

Prefiero mantener mis métodos en unidades lógicas de trabajo y realmente no me importan las métricas como LOC. Esto también hace que sea bastante fácil nombrar adecuadamente sus métodos y evita que sean hinchados.

Un ejemplo funcional muy trivial sería en lugar de tener una función que calcule la secuencia Fibonacci en línea en un bucle, agregaría una función sucesor (int a, int b), que se llama la función fibonacci ().

Un ejemplo más complejo en la moda OO sería un cliente HTTP que realiza una solicitud GET. Lo dividería en algo como esto:

Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)

Answer 10

Las funciones deben ser exactamente lo suficientemente pequeñas como para hacer su trabajo, pero no más pequeñas.