Longitud de archivo y ancho de línea 'recomendados' [cerrado]

Tenía curiosidad si alguien sabía de una recomendación de una fuente confiable para el número máximo de líneas de código para un archivo determinado. Por ejemplo, Closed Linter de Google recomienda que cada línea no supere los 80 caracteres.

Un archivo debe ser lo suficientemente corto como para que pueda encontrar cualquier función o método sin tener que desplazarse varias veces para buscarlo o tener que recordar una cadena de búsqueda. La métrica que uso es la cantidad de tiempo que paso buscando código dentro de un archivo en lugar de leerlo. Si eso se nota, es hora de volver a particionar el archivo o la clase.

Un buen tamaño para un bloque de código básico es lo suficientemente corto, tanto en ancho como en altura, para que pueda proyectar las entrañas durante una revisión de código de grupo, y tener todo en forma sin que la fuente sea tan pequeña que el tipo en la parte posterior de La sala de conferencias no puede leerlo. Este tamaño también ayuda si alguna vez se le llama para explicar algún código cuando todo lo que tiene con usted es un dispositivo móvil o tableta.

No existe tal cosa, y si la hubiera, dependería en gran medida del lenguaje que estuviera utilizando (haciendo lo mismo en ensamblador versus C # o Java, por ejemplo).

Para los idiomas de nivel superior, puede ver esta discusión SO. Para Java / C #, 10-20 líneas por método es lo que Bob Martin recomienda como máximo. No hay discusión sobre los archivos, ya que no es relevante y depende de lo que se supone que debe hacer la clase.

Con respecto al límite de 80 caracteres por línea, esto es un retroceso a los días de las tarjetas perforadas. Dicho esto, cuando las líneas crecen demasiado, la legibilidad sufre.

Las longitudes de archivo y línea son medidas de los efectos secundarios de la complejidad y, como tales, son muy variables. Lo que debe apuntar es código sin complejidad innecesaria, no un cierto recuento máximo de líneas.

Los archivos largos tienden a indicar que los métodos, las subrutinas o las clases son demasiado complejas (hacer demasiadas cosas, no están suficientemente factorizadas, etc.)

Las líneas largas tienden a indicar que las expresiones son demasiado complejas.

Son olores que indican un posible problema de código, métricas de destino no bien definidas.

La longitud de la línea debe ser tal que no tenga que desplazarse por la pantalla para ver la línea completa. Eso depende del tamaño y la resolución del monitor.

Los métodos y funciones son mejores si cabe en una pantalla.

Los archivos no deberían ser demasiado largos. Lo mejor son los archivos cortos, donde es fácil entender la clase y la implementación.
Una vez trabajé en un proyecto que tenía un archivo de 10 klines. Fue como leer un libro muy complejo. ¿Debo decir cuántos problemas causó la implementación?

80 caracteres!

Recuerdo que solía ver archivos de código fuente para programas de facturación de aproximadamente 80 páginas y más cuando hice COBOL. Por supuesto, no puedo ver que esto sea una práctica común, pero 80 caracteres es igualmente ridículo.

Desde una vista de tamaño de clase, si intenta aplicar esta sugerencia en una clase típica de Cliente que tiene alrededor de 80 propiedades y 20 métodos más o menos, tendrá que dividir la clase en varias otras y hacer que el código sea realmente desordenado.

Intento mantener las clases y los métodos cortos, pero no me preocupo demasiado por la longitud de la línea. En estos días de pantallas anchas e identificadores largos, creo que ochenta caracteres son muy pocos. Se necesita algo de trabajo para romper las declaraciones para que puedan leerse fácilmente, y con un límite de ochenta caracteres, sucede con bastante frecuencia. Creo que 120 o 130 columnas por línea es más razonable.