Cuenta de línea de clase de buena práctica

Question

Sé que no hay una respuesta correcta para esta pregunta, solo estoy pidiendo su opinión.

Sé que la creación de archivos de clase ENORMES con miles de líneas de código no es una buena práctica ya que es difícil de mantener y también significa que probablemente deba revisar la lógica de su programa.

En su opinión, ¿qué es un recuento medio de la línea para una clase digamos en Java (que no sé si la elección del idioma tiene nada que ver con esto, pero por si acaso ...)

Answer 1

Sí , Diría que tiene que ver con el lenguaje, aunque solo sea porque algunos lenguajes son más detallados que otros.

En general, utilizo estas reglas generales:

• < 300 líneas: finos
• 300 - 500 líneas: razonables
• 500 - 1000 líneas: quizás bien, pero en plan refactorización
• > 1000 líneas: definitivamente Refactor

por supuesto, lo que realmente depende más de la naturaleza y complejidad de la código que en LOC, pero he encontrado estos razonables.

Answer 2

En general, el número de líneas no es el problema; una medida ligeramente mejor es la cantidad de métodos públicos. Pero no hay una figura correcta. Por ejemplo, una clase de cadena de utilidad puede tener cientos de métodos correctamente, mientras que una clase de nivel empresarial puede tener solo un par.

Si le interesan las medidas LOC, ciclomáticas y otras de complejidad, recomiendo Source Monitor de http://www.campwoodsw.com, que es gratuito, funciona con los principales idiomas como Java & C++, y es genial.

Answer 3

Me centro en los métodos y (trato de) mantenerlos por debajo de 20 líneas de código. La duración de la clase en general está dictada por el principio de responsabilidad única. Pero creo que esto no es una medida absoluta, ya que depende del nivel de abstracción, por lo tanto, en algún lugar entre 300 y 500 líneas empiezo a buscar en el código una nueva responsabilidad o abstracción para extraer.

Answer 4

Eric Raymond de "El arte de Unix Programación"

En términos no matemáticos, los resultados empíricos de Hatton implica un punto dulce entre 200 y 400 líneas lógicas de código que reduce al mínimo la densidad probable defecto, todos los demás factores (tales como habilidad del programador) siendo igual. Este tamaño es independiente del idioma que se utiliza, una observación que refuerza fuertemente los consejos dados en otras partes de este libro para programar con los lenguajes y herramientas más potentes que pueda. Sin embargo, ten cuidado de tomar estos números demasiado literalmente. Los métodos para contar líneas de código varían considerablemente según lo que el analista considere una línea lógica, y otros sesgos (por ejemplo, si se eliminan los comentarios). El propio Hatton sugiere como regla general una conversión de 2x entre líneas lógicas y físicas, lo que sugiere un rango óptimo de 400-800 líneas físicas.

Tomado de here

Answer 5

Tienes razón ... no hay una respuesta a esto. No puede poner una "mejor práctica" como una cantidad de líneas de código.

Sin embargo, como una guía, a menudo me atengo a lo que puedo ver en una página. Tan pronto como un método no cabe en una página, empiezo a pensar que estoy haciendo algo mal. En lo que respecta a toda la clase, si no puedo ver todos los encabezados de método/propiedad en una página, entonces quizás deba comenzar a dividirla también.

Nuevamente, realmente no hay una respuesta, algunas cosas solo tienen que ser grandes y complejas. El hecho de que sepa que esto es malo y lo está pensando ahora, probablemente signifique que sabrá cuándo detenerse cuando las cosas se salgan de control.

Answer 6

Lo suficientemente pequeño como para hacer solo la tarea que le corresponde.

Lo suficientemente grande como para hacer solo la tarea que le corresponde.

No más, no menos.

Answer 7

Es mejor medir algo así como cyclomatic complexity y usar eso como un medidor. Incluso podría pegarlo en su script de compilación/archivo ant/etc.

Es demasiado fácil, incluso con un formato de código estandarizado, que las líneas de código se desconecten de la complejidad real de la clase.

Editar: Consulte this question para obtener una lista de las herramientas de complejidad ciclomática.

Answer 8

Las líneas de código son mucho más sobre la verbosidad que cualquier otra cosa. En el proyecto en el que estoy trabajando actualmente tenemos algunos archivos con más de 1000 LOC. Pero, si quitas los comentarios, probablemente se mantendrá alrededor de 300 o incluso menos. Si cambia las declaraciones como

 
int someInt; 
int someOtherInt; 

a una línea, el archivo será aún más corto.

Sin embargo, si no es prolijo y aún tiene un archivo grande, probablemente deba pensar en refactorizar.

Answer 9

La respuesta corta: menos de 250 líneas.

La respuesta más corta: Mu.

La respuesta más larga: ¿El código es legible y conciso? ¿La clase tiene una sola responsabilidad? ¿El código se repite?

Answer 10

En mi experiencia, cualquier archivo fuente de más de 1000 líneas de texto comenzaré queriendo romper. Idealmente, los métodos deberían caber en una sola pantalla, si es posible.

Últimamente he empezado a darme cuenta de que la eliminación de comentarios poco útiles puede ayudar mucho con esto. Comenta ahora más con moderación ahora que hace 20 años cuando comencé a programar.

Answer 11

Para mí, el problema no es LOC. Lo que veo es varios factores. Primero, reviso mis declaraciones If-Else-If. Si muchos de ellos tienen las mismas condiciones o si se ejecuta un código similar, trato de refactorizar eso. Luego miro mis métodos y variables. En cualquier clase, esa clase debe tener una función principal y solo esa función. Si tiene variables y métodos para un área diferente, considere ponerlos en su propia clase. De cualquier manera, evite contar LOC por dos razones:

1) Es una mala medida. Si cuenta LOC, está contando no solo líneas largas, sino también líneas que son espacios en blanco y se utilizan para comentarios como si fueran iguales.Puedes evitar esto, pero al mismo tiempo, sigues contando líneas pequeñas y líneas largas por igual.

2) Es engañoso. La legibilidad no es puramente una función de LOC. Una clase puede ser perfectamente legible, pero si tienes un recuento LOC que infringe, te encontrarás trabajando duro para exprimir tantas líneas como puedas. Incluso puede terminar haciendo que el código sea MENOS legible. Si toma el LOC para asignar variables y luego las usa en una llamada a método, es más legible que llamar a las asignaciones de esas variables directamente en la llamada al método. Es mejor tener 5 líneas de código legible que condensarlo en 1 línea de código ilegible.

En cambio, me gustaría ver la profundidad del código y la longitud de la línea. Estas son mejores métricas porque te dicen dos cosas. Primero, la profundidad anidada te dice si tu lógica necesita ser refactorizada. Si está mirando declaraciones If o bucles anidados más de 2 de profundidad, considere seriamente refactorizar. Considere refactorizar si tiene más de un nivel de anidación. En segundo lugar, si una línea es larga, generalmente es muy ilegible. Trata de separar esa línea en varias líneas más legibles. Esto podría romper su límite de LOC si tiene uno, pero en realidad mejora la legibilidad.

Answer 12

recuento de líneas == conteo de frijoles.

En el momento en que empiezas a emplear herramientas para averiguar cuántas líneas de código tiene un determinado archivo o función, estás jodido, en mi humilde opinión, porque dejaste de preocuparte por la manejabilidad del código y comenzaste a hacer reglas burocráticamente y echarle la culpa .

Eche un vistazo al archivo/función, y considere si todavía es cómodo trabajar con él, o comienza a volverse difícil de manejar. En caso de duda, llame a un co-desarrollador (o, si está ejecutando un show de un solo hombre, a un desarrollador no relacionado con el proyecto) para echar un vistazo y tener una conversación rápida al respecto.

Es realmente solo eso: una apariencia. ¿Alguien más obtiene inmediatamente la deriva del código, o es un libro cerrado para los no iniciados? Este rápido vistazo le brinda más información sobre la legibilidad de un fragmento de código que cualquier métrica de línea alguna vez ideada. Depende de tantas cosas. Idioma, dominio del problema, estructura del código, entorno de trabajo, experiencia. Lo que está bien para una función en un proyecto puede ser desproporcionado para otro.

Si se encuentra en una situación de equipo/proyecto y no puede estar de acuerdo con este enfoque de "vistazo rápido", tiene un problema social , no uno técnico. (Diferentes estándares de calidad, y posiblemente una falla de comunicación.) Tener reglas sobre la longitud de archivo/función no va a resolver su problema. Sentarse y hablar sobre una bebida fría (o un café, dependiendo ...) es una mejor opción.