function - ¿Cuántas líneas de código debe tener una función/procedimiento/método?
coding-style refactoring (6)
Posible duplicado:
¿Cuándo es una función demasiado larga?
Recientemente me dieron la tarea poco envidiable de revisar el código pobre escrito por otro desarrollador y documentar las malas prácticas. (¡Todo esto con el propósito de no pagar por el trabajo del desarrollador en lugar de por un motivo altruista, por supuesto!)
El código revisado tiene varios procedimientos que tienen muchas líneas de código: el más largo tiene casi 600 líneas. Un par de problemas con esto que he pensado son mantenibilidad y legibilidad.
El truco es que tengo que justificar a un lego por qué esta es una mala práctica y, si es posible, respaldarla con un libro de referencia bien considerado y actual. Las analogías también son buenas.
¿Algunas ideas?
Duplicado: ¿ Cuándo es una función demasiado larga?
Duplicado: ¿la mejor regla para el tamaño máximo de la función?
La respuesta real
No hay un numero especifico
Una respuesta concreta
Si tiene que justificar con algún número a abogados o algo así, descubra la cantidad máxima de líneas que se ajustan a una ventana típica del editor de desarrollo en su tienda, y úselo.
Práctica general
Ni siquiera deberías mirarlo de esa manera, pero no debería haber nada muy complejo en una función en particular.
Cada unidad de trabajo debe delegarse en su propio método de nombre descriptivo descriptivo de la unidad. Haga esto y todos sus métodos terminen minúsculos y legibles sin contar líneas ...
El mayor delincuente que veo es 3-4 + condiciones booleanas explotadas en el medio de una declaración de si. Envuelve todo eso en un booleano con un buen nombre, luego completa cualquier pieza que lo componga que sea compleja por sí misma.
En primer lugar, tenga en cuenta que la restricción de longitud está completamente separada de la métrica habitual, que es "¿la función solo hace una cosa y lo hace bien?" Si la respuesta a esa pregunta no es sí, la función probablemente no sea buena, independientemente de la duración.
Pertinente específicamente a la longitud máxima, una cita de Code Complete, generalmente considerada como uno de los mejores libros sobre el tema de las prácticas de codificación:
De vez en cuando, un algoritmo complejo conducirá a una rutina más larga, y en esas circunstancias, se debe permitir que la rutina crezca orgánicamente hasta 100-200 líneas. (Una línea es una línea de código fuente no en blanco, no en blanco). Décadas de evidencia dicen que las rutinas de tal longitud no son más propensas a errores que las rutinas más cortas. Deje que cuestiones como la profundidad de anidación, el número de variables 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.
Si desea escribir rutinas de más de 200 líneas, tenga cuidado. Ninguno de los estudios que informaron disminución de costos, disminución de las tasas de error o ambos con rutinas más grandes se distinguieron entre los tamaños superiores a 200 líneas, y es probable que se encuentre con un límite superior de comprensión a medida que pase 200 líneas de código.
Han pasado muchos años desde que leí esto, pero creo que fue en Learning Perl que recomendaron hacer un procedimiento, no más de lo que puede caber todo en la pantalla a la vez. Pensé que este era un buen criterio. He visto funciones más largas que todavía eran legibles debido a código repetitivo (por ejemplo, acceso a la base de datos y asignación de valores de propiedad), pero esas son la excepción en lugar de la norma.
La menor cantidad posible
No se trata de líneas de código. Como dicen Steve Mcconnell y Bob Martin (dos referencias bastante buenas sobre las mejores prácticas de codificación), un método debería hacer una cosa y solo una cosa. Sin embargo, muchas líneas de código que se necesitan para hacer eso son cuántas líneas debería tener. Si esa "única cosa" se puede dividir en cosas más pequeñas, cada una de ellas debe tener un método.
Buenas pistas de que su método está haciendo más de una cosa:
- Más de un nivel de sangría en un método (indica demasiadas ramas lógicas para hacer solo una cosa)
- "Saltos de párrafo": los espacios en blanco entre los grupos lógicos de código indican que el método está haciendo más de una cosa
Sólo para nombrar unos pocos. Bob Martin también dice que lo mantengas en torno a 10. Personalmente, por lo general trato de dispararle a 10. Si comienza a acercarse a los 20, eso es una bandera mental para prestar más atención a ese método. Pero, en última instancia, LoC es una mala medida para casi cualquier cosa. Solo es un indicador útil que puede señalar el problema real.
Para agregar al punto de Rex, también debe ser lo más breve posible. Bob Martin dice 10 o menos