¿En qué punto / rango es un archivo de código demasiado grande?

Estoy encontrando muchos archivos de línea 2-3k, y realmente no parece que deberían ser tan grandes.

¿Cuál es un buen criterio para llamar objetivamente a un archivo de código fuente "demasiado grande" ?, ¿existe una cantidad máxima de líneas que debería tener un archivo de código fuente?

Como modelo ideal, utilizo los siguientes criterios (con una lógica similar a la que sugirió Martin Beckett, es decir, pensar en términos de estructura lógica y no en términos de líneas de código):

Regla 1

Una clase por archivo (en C ++: una clase -> un encabezado y un archivo de implementación).

Regla 2

Siete se considera la cantidad de elementos que nuestro cerebro puede observar al mismo tiempo sin confundirse. Por encima de 7 nos resulta difícil mantener una visión general de lo que vemos. Por lo tanto: cada clase no debe tener más de 7-10 métodos. Una clase que tiene más de 10 métodos es probablemente demasiado compleja y debería intentar dividirla. La división es un método muy efectivo porque cada vez que divide una clase, reduce la complejidad de cada clase individual al menos en un factor de 2.

Regla 3

Un cuerpo de método que no cabe en una o dos pantallas es demasiado grande (supongo que una ventana de pantalla / editor tiene aproximadamente 50 líneas). Idealmente, puede ver todo el método en una ventana. Si este no es el caso, solo necesita desplazarse hacia arriba y hacia abajo un poco, sin olvidar la parte del método que se oculta. Por lo tanto, si tiene que desplazarse más de una pantalla hacia arriba o hacia abajo para leer todo el cuerpo del método, su método probablemente sea demasiado grande y puede perder fácilmente la descripción general.

Una vez más, dividir los métodos utilizando métodos de ayuda privados puede reducir la complejidad del método muy rápidamente (en cada división, la complejidad se reduce al menos a la mitad). Si introduce demasiados métodos de ayuda privada, puede considerar crear una clase separada para recopilarlos (si tiene más métodos privados que públicos, tal vez se oculte una segunda clase dentro de su clase principal).

Reuniendo estas estimaciones muy aproximadas:

• Como máximo una clase por archivo fuente.
• Como máximo 10 métodos públicos por clase.
• Como máximo 10 métodos privados por clase.
• Como máximo 100 líneas por método.

Por lo tanto, un archivo de origen que tiene más de 2000 líneas es probablemente demasiado grande y comienza a ser demasiado desordenado.

Esta es realmente una estimación muy aproximada y no sigo estos criterios sistemáticamente (especialmente porque no siempre hay tiempo suficiente para realizar una refactorización adecuada). Además, como sugirió Martin Beckett, hay situaciones en las que una clase es una gran colección de métodos y no tiene sentido dividirlos de manera artificial solo para hacer que la clase sea más pequeña.

De todos modos, en mi experiencia, un archivo comienza a volverse ilegible cuando no se respeta uno de los parámetros anteriores (por ejemplo, un cuerpo de método de 300 líneas que abarca seis pantallas o un archivo fuente con 5000 líneas de código).

No, no en términos de líneas de código. El controlador debe ser agrupación lógica. Ciertamente no debería haber múltiples clases en un archivo grande, por ejemplo

Si tuviera una clase que legítimamente tuviera unos cientos de métodos (no es imposible, por ejemplo, en el modelado 3D), sería mucho menos conveniente dividir eso en archivos arbitrarios. Solíamos tener que hacer esto cuando la memoria era escasa y los procesadores más lentos, y era un problema, constantemente buscando la definición de la función.

Cuando el código en él se vuelve imposible de mantener. es decir: no puede decir simplemente mirando el código si el método / clase / función que está buscando (y tiene que editar / depurar) está allí, o no, y si es así, dónde está.

Sin embargo, su elección y características de IDE / Editor influirán en la cuantificación real de este límite superior. Plegado de código , la función / método de lista, y la búsqueda será posponer el momento este desarrollo presenta un escenario.

Pero cuando lo hace, es hora de dividirlo.

Aquí hay una vista alternativa: está preguntando cómo limitar el tamaño del archivo. Mi opinión es que hay muchos factores que hacen que los archivos de código grandes sean muy problemáticos. A veces, el archivo de código es enorme, pero su contenido está bien agrupado y es extremadamente limpio, de modo que el tamaño no causa problemas significativos. He visto muchos archivos que son muy legibles a pesar del alto LOC.

En lugar de aprovechar la métrica LOC, preferiría pensar en usar los datos del historial para comprender con qué frecuencia el código se rompe en esos archivos grandes. Por lo general, la razón es que los desarrolladores no tienen tiempo de paciencia para verificar los otros lugares relevantes en el mismo archivo y realizar el cambio con la mentalidad de "solución rápida" sin suficiente comprensión.

El mayor peligro es la presencia de código de copiar y pegar. La codificación de copiar y pegar, naturalmente, también acelera el crecimiento LOC. Creo que eliminar copiar y pegar es aún más importante que mantener LOC por debajo de algún número mágico. Además de copiar y pegar puro, también existe un segundo peligro en los archivos grandes: la funcionalidad superpuesta. Cuanto más grande es el archivo, más probable es que termines reimplementando algún fragmento que ya está en alguna otra sección del mismo archivo.

Por lo tanto, siempre y cuando la relación de corrección de errores (relación de confirmaciones de corrección de errores a todos los envíos) es baja para los archivos más grandes, la situación es tolerable. Inténtalo git logy revisa cuántas de las confirmaciones están relacionadas con errores. O utilice una herramienta que pueda analizarlo y visualizarlo automáticamente, por ejemplo, Softagram .

Considera esto Metaphor. Cuando se trata de la longitud del código, creo que deberíamos considerar lo siguiente:

The Cat in The Hat (50 pp.)

y

Lord of The Rings (1,178 pp.)

No hay nada malo con eso Lord of the Rings. Es un libro fabuloso. The Cat in the HatTambién es un gran libro. Ambos pueden ser entendidos por un niño de 5 años, pero solo uno es más adecuado debido al contenido.

En mi opinión, escribir código debería tener sentido para un niño de 5 años siempre que podamos. Cyclomatic ComplexityEs un concepto importante que los desarrolladores deben considerar al generar código. Utilizando y creando bibliotecas para mejorar la funcionalidad y la reutilización del código tanto como sea posible. De esta manera, nuestro código puede decir más volúmenes de lo que vemos escrito.

La mayoría de nosotros no estamos escribiendo código de ensamblaje . Pero la raíz de nuestro código es el ensamblaje. Buscar en el ensamblaje de 10000 líneas es más difícil que 10000 líneas de python, si se hace correctamente.

Pero algunos trabajos requieren escribir entre 500 y 1000 líneas. Nuestro objetivo con el código debe ser escribir 300 líneas de código limpio.

Como desarrolladores, queremos escribir "El señor de los anillos". Hasta que tengamos un error y desearíamos estar escribiendo "Cat in the Hat". No hagas de la codificación una medida del ego. Simplemente haga que las cosas funcionen de manera simple.

Los desarrolladores no quieren documentar el código (personalmente me encanta el código documentado, no soy tan egoísta). Así que no escriba código que solo usted pueda entender / leer. Escribir Cat in the Hatcódigo

Todos sabemos que eres JRR Tolken (en tu cabeza). Recuerde que no tendrá nada que demostrar con un código libre de errores.

Otra razón para la metáfora.

No exageres al lector, extiende la riqueza. Si trabajas con un grupo de personas y todas ellas tienen que cambiar ese mismo archivo, es probable que te estés gitfusionando.

Todos aman el rebase.

-> Dijo nadie nunca!

TL; DR Enfoque en la legibilidad. Extienda su código y ayudante en múltiples líneas y archivos tanto como pueda. No arroje 8 o 9 clases en un solo archivo, hace que el código sea difícil de leer y más difícil de mantener. Si tiene un código o bucle de condición grande, considere cambiarlos a Lambdas si el idioma lo admite. Las funciones de servicios públicos deben considerarse una gran vía para aumentar la legibilidad del código. Evite la anidación pesada.