code size - sociales - Recuento de buenas prácticas en línea
buenas practicas de comunicacion en redes sociales (12)
Sé que no hay una respuesta correcta a esta pregunta, solo pido sus opiniones.
Sé que crear archivos de clase HUGE con miles de líneas de código no es una buena práctica ya que es difícil de mantener y, por lo general, significa que probablemente debería revisar la lógica de su programa.
En su opinión, ¿qué es un conteo promedio de líneas para una clase, digamos en Java (no sé si la elección del idioma tiene algo que ver con eso, pero por si acaso ...)
De Eric Raymond "The Art Of Unix Programming"
En términos no matemáticos, los resultados empíricos de Hatton implican un punto dulce entre 200 y 400 líneas lógicas de código que minimizan la densidad de defectos probables, siendo iguales todos los demás factores (como la habilidad del programador). Este tamaño es independiente del idioma que se usa, una observación que refuerza en gran medida los consejos que se dan en otras partes de este libro para programar con los idiomas y herramientas más poderosos que pueda. Tenga cuidado de tomar estos números demasiado literalmente sin embargo. Los métodos para contar las líneas de código varían considerablemente según lo que el analista considera 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 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
En general, el problema no es la cantidad de líneas: una métrica 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 correctamente cientos de métodos, mientras que una clase de nivel empresarial puede tener solo un par.
Si está interesado en las mediciones de complejidad LOC, ciclomática y otras, le recomiendo encarecidamente el Monitor de origen de http://www.campwoodsw.com , que es gratuito, funciona con los principales lenguajes como Java y C ++ y es excelente.
En mi experiencia, cualquier archivo fuente de más de 1000 líneas de texto comenzaré a querer dividir. Idealmente, los métodos deberían caber en una sola pantalla, si es posible.
Últimamente, me he dado cuenta de que eliminar comentarios inútiles puede ayudar mucho con esto. Comento con mucho más moderación ahora que hace 20 años cuando comencé a programar.
Es mejor medir algo como la complejidad ciclomática y usar eso como un indicador. 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.
Edición: consulte esta pregunta para obtener una lista de las herramientas de complejidad ciclomática.
La respuesta corta: menos de 250 líneas.
La respuesta más corta: Mu.
La respuesta más larga: ¿Es el código legible y conciso? ¿La clase tiene una sola responsabilidad? ¿Se repite el código?
Lo suficientemente pequeño como para hacer solo la tarea que está encargada.
Lo suficientemente grande como para hacer solo la tarea que está encargada.
Ni mas ni menos.
Me concentro en los métodos y (trato de) mantenerlos por debajo de 20 líneas de código. La longitud de la clase en general está dictada por el principio de responsabilidad única. Pero creo que esto no es una medida absoluta porque 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 que extraer.
Para mí, el problema no es LOC. Lo que miro es varios factores. En primer lugar, reviso mis declaraciones If-Else-If. Si muchos de ellos tienen las mismas condiciones, o si se ejecuta un código similar, intento refactorizar eso. Entonces miro mis métodos y variables. En cualquier clase, esa clase debe tener una función primaria y solo esa función. Si tiene variables y métodos para un área diferente, considere colocarlos en su propia clase. De cualquier manera, evite contar LOC por dos razones:
1) Es una mala métrica. Si cuenta LOC, no solo se cuentan las líneas largas, sino también las líneas que son espacios en blanco y se usan para comentarios como si fueran lo mismo. Puedes evitar esto, pero al mismo tiempo, sigues contando líneas pequeñas y 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 tiene un conteo de LOC que viola, se encontrará trabajando duro para exprimir tantas líneas como sea posible. Incluso puede terminar haciendo el código MENOS legible. Si toma el LOC para asignar variables y luego las usa en una llamada de método, es más legible que llamar las asignaciones de esas variables directamente en la llamada de método. Es mejor tener 5 líneas de código legible que condensarlo en 1 línea de código ilegible.
En su lugar, 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 le dice si su lógica necesita ser refaccionada. Si está viendo Si las afirmaciones o los bucles están anidados a más de 2 de profundidad, considere seriamente la refactorización. Considere la refactorización si tiene más de un nivel de anidación. Segundo, si una línea es larga, generalmente es muy ilegible. Intenta 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.
Sí, diría que tiene que ver con el idioma, aunque solo sea porque algunos idiomas son más detallados que otros.
En general, utilizo estas reglas de oro:
- <300 líneas: fina
- 300 - 500 líneas: razonable
- 500 - 1000 líneas: tal vez está bien, pero planea refactorizar
- > 1000 líneas: definitivamente refactor
Por supuesto, realmente depende más de la naturaleza y complejidad del código que de LOC, pero me parece razonable.
Tienes razón ... no hay respuesta a esto. No puede poner una "mejor práctica" como una cantidad de líneas de código.
Sin embargo, como guía, a menudo veo 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 concierne a toda la clase, si no puedo ver todos los encabezados de métodos / propiedades en una página, tal vez deba comenzar a dividir eso también.
Una vez más, sin embargo, realmente no hay una respuesta, algunas cosas solo tienen que ser grandes y complejas. El hecho de que sepa que esto es malo y que lo esté pensando ahora, probablemente significa que sabrá cuándo detenerse cuando las cosas se salen de control.
conteo de líneas == conteo de frijoles.
En el momento en que empiezas a emplear herramientas para descubrir cuántas líneas de código tiene un determinado archivo o función, te atormentas, IMHO, porque dejaste de preocuparte por la capacidad de manejo del código y comenzaste a hacer reglas burocráticamente y culparte.
Eche un vistazo al archivo / función, y considere si todavía es cómodo trabajar con él o si comienza a volverse inoportuno. En caso de duda, llame a un co-desarrollador (o, si está ejecutando un show de un solo hombre, algún desarrollador no relacionado con el proyecto) para echarle un vistazo y conversar rápidamente al respecto.
Realmente es solo eso: una mirada . ¿Alguien más recibe inmediatamente la deriva del código, o es un libro cerrado para los no iniciados? Este vistazo rápido le brinda más información sobre la legibilidad de un fragmento de código que cualquier métrica de línea jamás creada. Depende de tantas cosas. Lenguaje, dominio del problema, estructura de código, ambiente 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 "una mirada rápida", tiene un problema social , no técnico. (Diferentes estándares de calidad y posiblemente un fallo de comunicación). Tener reglas sobre la longitud de los archivos / funciones no resolverá su problema. Sentarse y hablar sobre un refresco (o un café, dependiendo de ...) es una mejor opción.
Las líneas de código tienen mucho más que ver con la verbosidad que con cualquier otra cosa. En el proyecto en el que estoy trabajando actualmente tenemos algunos archivos con más de 1000 LOC. Pero, si elimina los comentarios, probablemente se mantendrá alrededor de 300 o incluso menos. Si cambias declaraciones como
int someInt; int someOtherInt;
a una línea, el archivo será aún más corto.
Sin embargo, si no está detallado y aún tiene un archivo grande, probablemente deba pensar en la refactorización.