Bienvenido a proyecto online, en este sitio encontrarás la solucíon que estabas buscando.
Solución:
No se trata de líneas de código. Como Steve McConnell y Bob Martin dice (dos referencias bastante buenas sobre las mejores prácticas de codificación), un método debe hacer una cosa y solo una cosa. Sin embargo, cuántas líneas de código se necesitan para hacer eso, una cosa es cuántas líneas debería tener. Si esa “cosa única” se puede dividir en cosas más pequeñas, cada una de ellas debería 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 estar haciendo solo una cosa)
- “Saltos de párrafo”: los espacios en blanco entre 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 mantenga alrededor de 10. Personalmente, generalmente trato de apuntar a 10. Si comienza a acercarse a 20, es una bandera mental para prestar más atención a ese método. Pero, en última instancia, las líneas de código son una mala métrica para casi cualquier cosa. Es solo un indicador útil que potencialmente puede señalar el problema real.
la verdadera respuesta
No hay un número específico.
Una respuesta concreta
Si tiene que justificar con algún número a los abogados o algo así, calcule el número máximo de líneas que caben en una ventana típica del editor de desarrollo en su tienda y utilícelo.
Práctica general
Ni siquiera debería verlo de esa manera, pero no debería haber nada muy complejo en ninguna función.
Cada unidad de trabajo debe ser delegada a su propia unidad comprobable método descriptivo llamado. Haga esto y todos sus métodos terminarán diminutos y legibles sin tener que contar líneas…
El mayor infractor que veo es 3-4+ condiciones booleanas explotadas en medio de una declaración if. Envuelva todo eso en un booleano con un buen nombre, luego envuelva cualquier pieza que lo componga que sea compleja en sí misma.
En primer lugar, tenga en cuenta que la restricción de longitud es completamente independiente de la métrica habitual, que es “¿la función hace solo una cosa y la hace bien?” Si la respuesta a esa pregunta no es sí, la función probablemente no sea buena de todos modos, independientemente de la longitud.
Relevante específicamente para la longitud máxima, una cita de Code Complete, generalmente considerado 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 sin comentarios ni 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 anidamiento, 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 reducción de costos, reducción de tasas de error, o ambos con rutinas más grandes distinguieron entre tamaños superiores a 200 líneas, y es probable que se encuentre con un límite superior de comprensibilidad al pasar 200 líneas de código.