LOC es probablemente una de las métricas más abusadas, y como resultado es probablemente una de las medidas más inútiles de la calidad del código, y una medida aún más inútil del esfuerzo de programación.
Sí, esa es una declaración audaz para mí, y no, no puedo señalarle estudios que prueben mi punto. Sin embargo, puedo afirmar con una experiencia dura que cuando empiezas a preocuparte por la cantidad de código que has escrito, probablemente te preocupes por los problemas incorrectos.
Primero debe preguntarse qué es lo que está tratando de medir o probar, y si esta prueba es simplemente por interés, o para apoyar una mejora de calidad más amplia y dónde necesita usar esta información para obtener la aceptación de su equipo / gestión para hacer algo al respecto.
Una de las cosas para las que tiendo a usar LOC es un poco de verificación de cordura. Si me encuentro escribiendo mucho código, me intereso más en LOC por método, o LOC por clase, en lugar de LOC en general. Estas medidas pueden ser indicadores que debe refactorizar aún más si siente un poco de TOC sobre qué tan bien factorizado debe ser su código. Es posible que las clases muy grandes necesiten ser refactorizadas en unas pocas clases más pequeñas, y los métodos largos de varias líneas pueden desglosarse en varios métodos, otras clases, o incluso pueden indicar alguna repetición que podría eliminarse. Observe que usé la palabra "poder" varias veces allí.
La realidad es que LOC solo proporciona un posible indicador, y no hay una garantía real de que su código deba cambiar. La verdadera pregunta es si el código se comporta como se requiere y como se espera. Si es así, su próxima pregunta es si podrá o no mantener el código fácilmente y si tendrá tiempo ahora o en el futuro para realizar cambios en el código de trabajo para reducir sus gastos generales de mantenimiento en el futuro.
A menudo, un montón de código significa que tendrá más para mantener más tarde, pero a veces incluso un código bien factorizado puede extenderse a cientos de líneas de código, y sí, a veces puede encontrarse escribiendo cientos de líneas de código en un día. Sin embargo, la experiencia me dice que si mantengo una salida de cientos de líneas de código nuevo cada día, a menudo existe el riesgo de que gran parte del código se haya cortado y pegado de manera inapropiada en otro lugar, y eso en sí mismo puede indicar problemas con duplicación y mantenimiento, pero nuevamente eso no es garantía, por lo que tiendo a confiar en lo que mi experiencia e instintos me dicen en función de cómo se completaron las tareas en cuestión.
La mejor manera de evitar el dilema planteado en su pregunta en mi humilde opinión es olvidarse de LOC y refactorizar TODO el tiempo. Primero escriba su prueba de código, implemente para fallar, refactorice para pasar, luego vea qué se puede refactorizar allí y luego mejore el código. Abandonarás la tarea sabiendo que ya has verificado tu trabajo, y no te preocupará tanto cuestionarte en el futuro. Hablando de manera realista, si usa un enfoque de prueba primero como lo he descrito, cualquier medición de LOC / día en su código completado realmente significará que ha escrito 3-5 veces la cantidad medida, con ese esfuerzo ocultado con éxito por su refactorización en curso esfuerzos