Aquí hay muchas respuestas que abordan los pros y los contras técnicos de mantener el LOC bajo y si es o no una métrica de software de calidad significativa. De eso no se trata esta pregunta. De lo que se trata es cómo lidiar con la administración que insiste en una ingenua adhesión dogmática a una regla general de codificación en particular.
Lamentablemente, es bastante común que las personas se adhieran a cosas que son un buen consejo cuando se usan en el contexto adecuado y se aplican de manera pragmática, las sacan de ese contexto y las aplican dogmáticamente mientras no aprecian los problemas que existen para mitigarlos. El primer lugar.
La intención de los consejos con respecto a mantener el LOC bajo es evitar la creación de métodos que intentan hacer demasiado de una sola vez, y desalentar la creación de "clases de dios", que saben demasiado sobre aspectos de un diseño que no están No es su responsabilidad directa y de la que dependen todas las demás clases en el sistema. Otra ventaja del código más corto es que es más legible, aunque, como lo has señalado, puedes exagerar hasta el punto en que la legibilidad realmente comienza a sufrir.
Los recuentos LOC bajos presentan ventajas obvias (los métodos pequeños encajan en su cabeza más fácilmente que los grandes, menos cosas en el código significan que hay menos cosas que salen mal, etc.), pero también están sujetos a la ley de rendimientos decrecientes . Refactorizar un método de 150 líneas en un número de métodos de 20 líneas es una ganancia mucho más grande que refactorizar un método de 10 líneas en un método de 7 líneas.
Cuando dicha refactorización se produce a expensas de alguna otra faceta del buen diseño del software (como la legibilidad), ha llegado a un punto en el que puede justificar que no lo haga. Eliminar las variables que dan contexto a lo que significa el código y reemplazarlos con literales que no lo hacen es algo muy malo. El buen código casi no tiene literales. Sin embargo, estas variables (y las constantes nombradas) son líneas de código que no contribuyen directamente al programa y, por lo tanto, si LOC se está adorando como una especie de dios, dichas líneas de clarificación están en gran peligro de ser eliminadas para una victoria rápida. Algunos elogios equivocados de la gestión.
Creo que eres lo suficientemente inteligente como para darte cuenta de esto, de hecho, esa es la orientación de tu pregunta original. El problema no es su comprensión de cuándo la reducción del código es buena y cuando no lo es, el problema es el dogmatismo en la aplicación de lo que normalmente es una práctica razonable indiscriminadamente.
Recomendaría tomarse el tiempo para conversar con su gerencia, explicando su posición y por qué cree que lo que se le pide que haga dañe el código en lugar de ayudarlo. Trate de evitar la confrontación, pero trate de mantenerse racional y calmado durante tal discusión. Es importante que su gerencia entienda que la programación es una actividad pragmática, y los consejos de mejores prácticas solo son útiles si se aplican de manera pragmática. La mejor práctica está escrita en un libro, no está tallada en piedra, y cuando entra en conflicto (código corto versus código legible), entonces depende del programador aplicar su criterio en cuanto a qué mejor práctica seguir. Esperemos que sean personas razonables que aprecian comentarios como este.
También debe ser un poco valiente, porque si se le presiona para que reduzca la LOC cuando crea que es innecesario o inapropiado, entonces es natural que haga el cambio de todos modos por una vida tranquila. Tienes que resistirte a hacer esto, y tienes que "apropiarte" de esa decisión. En una situación en la que la administración es razonable, no debería tener que cumplir exactamente con sus directrices, pero debería poder justificar cualquier circunstancia en la que no lo haga.
Lamentablemente, las personas pueden ser irracionales, especialmente cuando se trata de personas más bajas en el orden jerárquico que cuestionan sus decisiones y las reglas que te han impuesto. Pueden elegir no ser razonables. Necesitas estar preparado para eso también. Si puede demostrar los casos en que la mejor práctica de LOC entra en conflicto directo con otras mejores prácticas y por qué está dañando el producto, y si puede hacerlo en partes del código base para el cual tuvieron poca o ninguna participación personal (por lo que no No parezca un ataque personal a su trabajo o el trabajo que supervisaron, entonces esto puede ayudar a reforzar su argumento. Una vez más, debes estar preparado para justificarte de manera calmada y racional y ser capaz de "poseer" los argumentos que estás formulando.
Siempre que su administración sea una persona razonable, deben apreciar que lo que usted dice tiene mérito si puede proporcionar evidencia para respaldar sus reclamaciones.