¿Cuántas líneas por clase son demasiadas en Java? [cerrado]

Algunas métricas interesantes:

            junit  fitnesse testNG    tam     jdepend    ant     tomcat
            -----  -------- ------    ---     -------    ---     ------
max           500       498   1450    355         668   2168       5457
mean         64.0      77.6   62.7   95.3       128.8  215.9      261.6
min             4         6      4     10          20      3         12
sigma          75        76     110    78         129    261        369
files          90       632   1152     69          55    954       1468
total lines  5756     49063   72273  6575        7085 206001     384026

Utilizo FitNesse como punto de referencia porque tuve mucho que ver con escribirlo. En FitNesse la clase promedio es de 77 líneas de largo. Ninguno es más largo que 498 líneas. Y la desviación estándar es de 76 líneas. Eso significa que la gran mayoría de las clases son menos de 150 líneas. Incluso Tomcat, que tiene una clase que supera las 5000 líneas, tiene la mayoría de las clases de menos de 500 líneas.

Dado esto, probablemente podamos usar 200 líneas como una buena guía para permanecer abajo.

Para mí, las líneas de código son irrelevantes en este contexto. Se trata de la cantidad de razones diferentes por las que vendría a esta clase para cambiarlo.

Si quisiera asistir a esta clase cuando quisiera cambiar las reglas para validar a una Persona, no quiero venir a la misma clase para cambiar las reglas para validar una Orden, ni tampoco quiero venir aquí para Cambiar donde persista una persona.

Dicho esto, si apuntas a eso, rara vez encontrarás clases de más de 200 líneas. Ocurrirán, por razones válidas, pero serán raras. Entonces, si está buscando una métrica de bandera roja, entonces no es un mal lugar para comenzar; pero haz que sea una pauta, no una regla.

Lo siento, pero estoy muy sorprendido de que muchas respuestas digan que "realmente no importa". Mucho importa cuántas líneas hay en una clase. ¿Por qué? Considere estos principios al escribir un buen código Java ...

• Probabilidad
• Cohesión
• acoplamiento
• comprensibilidad

Las clases con muchas líneas en ellas probablemente violarán todos esos principios.

Para aquellos que lo han dicho "realmente no importa" ... ¿qué tan divertido ha sido para usted intentar comprender una clase que tiene más de 5000 líneas? ¿O modificarlo? Si dices que es divertido, tienes una extraña afinidad con el dolor ...

Yo diría que cualquier clase que tenga más de 1000 líneas debería al menos cuestionarse sobre cómo pueden estar violando los principios anteriores y posiblemente analizarse en varias clases "fuera de rodaje".

Mis comentarios se basan en la lectura y el estudio de autores como Martin Fowler, Joshua Bloch y Misko Hevery. Son excelentes recursos para consultar para escribir un buen código Java.

Haz del siguiente chico (que podrías ser tú en un par de años) un favor y esfuérzate por escribir clases que tengan menos en lugar de más líneas.

Depende de la complejidad, no del número de líneas. He escrito grandes rutinas tontas que eran fáciles de entender y que hacían precisamente una cosa y las hacían bien, pero seguían cientos de líneas. He escrito funciones bastante cortas que eran difíciles de entender (y depurar).

Otra cosa que podría observar es el número de funciones públicas en una clase. Eso también puede ser una señal de advertencia.

No tengo buenos conteos disponibles, pero sugeriría que veas un código decente que haga cosas útiles en tu tienda, y que se base en eso. Ciertamente, deberías mirar las clases más largas y las API más grandes.

La respuesta correcta es 42. Es broma.
En realidad, las líneas máximas recomendadas por clase son 2000 líneas.

Los "convenios de código de Java" desde 1999 lo han expresado de esta manera:
Los archivos de más de 2000 líneas son engorrosos y deben evitarse.

Habiendo seguido las convenciones de codificación de Sun / Oracle desde que se inventó Java, He encontrado que esta regla de oro en las líneas por clase es razonable. El 99% de su código Java debe ajustarse ... Y si supera los 2000, simplemente ponga un TODO en la parte superior diciendo que la clase necesita trabajo.

Lo peor es el caso opuesto cuando los programadores crean demasiados minúsculos. Pequeñas clases con casi ninguna funcionalidad real en cada clase. Ignorando el consejo de "Favorecer la composición", los programadores crean cientos de clases heredadas que crean modelos de objetos complicados que son mucho peores que el problema de la clase grande (que al menos generalmente mantiene la funcionalidad con un nombre de clase relevante).

enlace

Hay demasiadas líneas de código si la clase está haciendo muchas cosas diferentes. Esencialmente, si sigues el principio de Responsabilidad única para las clases, hay un límite en el tamaño de la clase.

En cuanto a las limitaciones físicas que puede tener (fuente: Formato de archivo de clase Java5 ):

• 65,536 constantes, interfaces aplicadas, campos, métodos y atributos, cada uno. NOTA: se quedará sin espacio constante antes de quedarse sin cualquiera de los otros elementos. NOTA 2: los atributos son construcciones de archivos de clase, que no deben confundirse con los marcadores '@Attribute' (es decir, la información de depuración y el código de bytes se almacenan como atributos separados para un método).
• Cada método puede ser de 4 GB (32 bits) de código de byte generado. NOTA: las versiones de Java anteriores a 1.5 solo podían tener 64 KB (16 bits) de código de byte generado para cada método.

En resumen, el archivo de clase puede ser mucho más grande de lo que cualquier persona consideraría útil. Si se adhiere al principio de responsabilidad única, sus archivos de clase tendrán el tamaño correcto.

Código de limpieza:

  

¡Las clases deben ser pequeñas!

     

La primera regla de las clases es que deben ser pequeñas. La segunda regla de las clases es que deben ser   más pequeño que eso. No, no vamos a repetir exactamente el mismo texto.   del capítulo Funciones. Pero como con las funciones, más pequeño es el.   Regla primaria a la hora de diseñar clases. Como con las funciones,   nuestra pregunta inmediata es siempre "¿Qué tan pequeño?"

     

** Con las funciones medimos el tamaño contando las líneas físicas. Con las clases utilizamos una medida diferente. Contamos responsabilidades. **

     

El nombre de una clase debe describir qué responsabilidades cumple. De hecho, nombrando   Es probablemente la primera forma de ayudar a determinar el tamaño de la clase. Si no podemos derivar un conciso   nombre de una clase, es probable que sea demasiado grande. Cuanto más ambiguo sea el nombre de la clase, más   Es probable que tenga demasiadas responsabilidades. Por ejemplo, nombres de clase que incluyen palabras de comadreja   como Processor o Manager o Super a menudo insinúan una agregación desafortunada de   responsabilidades.

Entonces:

• Solo asegúrate de que tus métodos solo hagan una cosa.
• Luego, asegúrese de que la clase no tenga demasiadas responsabilidades.

Terminarás con una clase de un tamaño manejable.

El número de líneas es una métrica bastante pobre para la calidad de clase. Para mí, me gusta ver (como otros lo han mencionado) métodos públicos, así como cualquier propiedad expuesta públicamente (supongo que hay captadores / configuradores públicos en Java). Si tuviera que sacar un número del aire para cuando pudiera captar mi atención, diría que hay más de 10 de cada uno. Realmente, si es más de aproximadamente 5 de cualquiera de las propiedades o métodos, echaré un vistazo y a menudo encontraré formas de refactorizar, pero cualquier cosa por encima de 10 suele ser una señal de advertencia de que es probable que algo esté poco expuesto.

Es otra conversación completamente, pero los métodos y campos privados son menos olor para mí, por lo que si están contribuyendo mucho al número de líneas, es posible que no esté tan preocupado. Como mínimo, muestra que probablemente no haya un controlador de Dios que manipule el objeto desde lejos, lo que es un problema de diseño bastante problemático.

Intenta usar una métrica mejor.

Un ejemplo es el ABC Metric . Es más una medida de cuánto trabajo está haciendo el código que de cuánto código hay.

Cualquier línea que caiga dentro del dominio de problemas de su clase escrita fuera de la clase es una línea muy poca y demasiada en la clase donde vive. Piense en una clase como un tema. Tienes que cubrirlo. Lo ideal es lo más conciso posible, pero si toma 500 líneas, toma 500 líneas. Si 100 de esas líneas cubren otro tema, pertenecen a otro lugar. Irrumpir en subdominios más pequeños dentro de la clase como clases interiores tiene sentido, pero solo definiría aquellas fuera de la clase si tuvieran uso en otra parte.