¿Qué tan importante es reducir la cantidad de líneas en el código?

Soy un desarrollador de software que trabaja en J2SE (core java).
A menudo, durante las revisiones de nuestro código, se nos pide que reduzcamos el número de líneas en nuestro código.

No se trata de eliminar código redundante, se trata de seguir un estilo que se centre en hacer las mismas cosas con menos líneas en el código, mientras que creo en tener claridad en el código, incluso si eso significa aumentar el número de líneas.

¿Cuál crees que es la forma correcta de hacer las cosas?
Si LOC (líneas de código) es un número pequeño, ¿cómo afecta al código? Si LOC es un número mayor, ¿cómo afecta el código?

ejemplo del sitio web: "javaranch" -

public static void happyBirthday(int age)
{  
    if ((age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))))        
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

VS

public static void happyBirthday(int age)
{

    boolean sweet_sixteen = (age == 16);
    boolean majority = (age == 21);
    boolean adult = (age > 21);
    boolean decade = (age % 10) == 0;
    boolean quarter = (age % 25) == 0;

    if (sweet_sixteen || majority || (adult && (decade || quarter)))
    {
        System.out.println("Super special party, this year!");
    }
    else
    {
        System.out.println("One year older. Again.");
    }
}

El problema con las mediciones, sin importar cuán bien intencionadas sean, es que el acto mismo de medir el artículo lo hace importante, y el corolario, el acto de no medir un artículo lo hace poco importante. Es absolutamente esencial medir lo que es importante, y no medir lo que no es importante.

La medición de SLOC (que es efectivamente lo que hacen sus comentarios) hace que SLOC sea importante ... ¿Es importante SLOC? - absolutamente no, nunca ha estado (fuera de concursos de programación ofuscada ), nunca estará en una organización comercial.

Hágase una pregunta simple: cómo "Reducir el SLOC de esta rutina" mejora el código de anyones. Lo que probablemente esté sucediendo en este caso es que SLOC se está utilizando como una forma ingenua de medir la complejidad. Lo que debe evitar a toda costa es contar los frijoles fáciles de contar: medidas objetivas como SLOC, en lugar de contar las importantes, pero difíciles de contar, por ejemplo, legibilidad, complejidad, etc.

Estoy de acuerdo con sus revisores de código, pero con un asterisco. Cada declaración que escriba en su código es una responsabilidad técnica, es un posible punto de falla. Si escribe un método con 10 declaraciones y su compañero de trabajo escribe uno que logre la misma funcionalidad con 5 declaraciones, es probable que el suyo sea 'mejor' medido por la probabilidad de problemas (hay dos veces más lugares en los que su código puede estar equivocado, demasiado) complejo o problemático).

Aquí está el asterisco, sin embargo. No se trata de la cantidad real de líneas de código en la idea porque puede reducir la cantidad de líneas con algo como:

void someMethod() {   
 someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

Esta es una línea de código, pero es un lugar donde una cantidad sorprendente de cosas puede salir mal. Así que diría que concéntrese en hacer lo máximo con la menor cantidad de declaraciones: escriba todo el código que necesite para hacer las cosas y nada más. Al menos, creo que es a lo que están conduciendo sus revisores de código.

Personalmente, creo que hay que lograr un equilibrio. Como dije, cada declaración que escriba es una responsabilidad, pero si extraer una variable local con un nombre descriptivo hace que su método sea mucho más claro y legible, entonces también hay un caso para eso. Creo que puede entrar fácilmente en situaciones en las que las personas están discutiendo sobre diferencias estéticas relativamente menores, pero en general, creo que sus revisores tienen la idea correcta: favorezca minimizar la cantidad de cosas que pueden salir mal.

Seguir los consejos de los revisores, literalmente, no servirá de nada, porque el resultado directo obvio es la promoción de líneas generales (no obstante el límite de longitud de línea). Sin embargo, creo que la lección que se debe aprender aquí es hacer que su código haga menos cosas .

En otras palabras, esta es una llamada a la simplicidad. Es una afirmación bastante popular que el código es una responsabilidad, no un activo , por lo que reducir su cantidad al tiempo que preserva la funcionalidad es un esfuerzo noble. Esto se puede lograr mediante un enfoque directo y más realista que aborde el problema directamente y prefiera soluciones concisas.

Como Ken Thompson dijo una vez: Uno de mis días más productivos fue tirar 1000 líneas de código .

Tiendo a estar de acuerdo con su posición de "tener claridad en el código, incluso si eso significa aumentar el número de líneas".

He visto demasiadas frases que son bastante concisas, pero no es evidente de inmediato lo que están haciendo. La legibilidad es el rey ya que otros desarrolladores tendrán que mantener su código.

Yo diría que es mejor apuntar a métodos cortos. No es corto por el bien de pocas líneas de código, sino corto porque hacen una sola cosa.

Actualmente trabajo como desarrollador senior de aplicaciones y analista de negocios de proyectos para una empresa importante y nunca ha sido el centro de interés el recuento de líneas de mi desarrollo. Sin embargo, creo que cuanto más condensado puede ser un código, mejor, PERO no a costa de poder analizarlo y corregirlo (o agregarlo) rápidamente. Para mí, cuando está a cargo de una aplicación comercial crítica que DEBE tener un gran nivel de escalabilidad y capaz de alteraciones sobre la marcha en un entorno de cambio continuo, el código conciso y fácil de leer es uno de los elementos más importantes en el desarrollo . Para el crédito de la respuesta de Erik Dietrich , esto:

void someMethod() {   
someobject.doSomething(someSingleton.getInstance().with().a().lot().of().law().of().demeter().violations()).and().if().that().werent().enough().theres().more();
}

sería completamente inaceptable para mí, sin embargo, encontré alterar el código existente de todas las compañías de:

if (boolean == true){
value.prop = option1;
}
else{
value.prop = option2;
}

a:

value.prop =  boolean ? option1 : option2;

fue una excelente opción de condensación de código que no sacrifica la legibilidad.

¿En cuanto a cómo afecta el código? Nunca he notado un aumento o disminución del rendimiento de, digamos, 100 líneas de código. El hecho simple es que es más el proceso que utiliza para llegar al producto final que la cantidad de líneas que se necesitan para llegar allí. He visto algunos procesos escritos muy condensados, aunque ineficientes, funcionan de manera diferente que los códigos más largos con un mejor flujo de código.

En mi opinión, es una mala idea medir la efectividad del código mediante un recuento trivial de LOC. Hay mucho más en lo que hace que el código sea diseñado y efectivo de manera adecuada.

En mi experiencia, código efectivo:

• no rompe ninguno de los principios SÓLIDOS
• es legible y se explica por sí mismo
• pasa la prueba de simplicidad de Albert Einstein: "Todo debe hacerse lo más simple posible, pero no más simple".

Aquí hay muchas respuestas que abordan los pros y los contras técnicos de mantener baja la LOC 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 de cómo tratar con la administración que insiste en una adhesión dogmática ingenua a una regla general de codificación particular.

Lamentablemente, es bastante común que las personas se aferren a cosas que son un buen consejo cuando se usan en el contexto adecuado y se aplican de manera pragmática, sacarlas de ese contexto y aplicarlas dogmáticamente sin poder apreciar los problemas que el consejo existe para mitigar en primer lugar .

La intención del consejo sobre mantener baja la LOC es evitar la creación de métodos que intenten hacer demasiado de una vez y desalentar la creación de "clases de dios", que saben demasiado sobre aspectos de un diseño que no son suyos. responsabilidad directa y de la que dependen todas las demás clases del sistema. Otra ventaja del código más corto es que es más legible, aunque, como lo ha señalado, puede exagerar hasta el punto en que la legibilidad realmente comience a sufrir.

Existen ventajas obvias en los recuentos bajos de LOC (los métodos pequeños se ajustan a su cabeza más fácilmente que los grandes, menos cosas en el código significan menos cosas que salgan mal, etc.), pero también está sujeto a la ley de rendimientos decrecientes. Refactorizar un método de 150 líneas en varios métodos de 20 líneas es una ganancia mucho mayor 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 de software (como la legibilidad), ha llegado a un punto en el que puede justificar no hacerlo. Eliminar las variables que dan contexto a lo que significa el código y reemplazarlas con literales que no lo hacen es algo muy malo. Un buen código casi no tiene literales. Sin embargo, estas variables (y constantes con nombre) son líneas de código que no contribuyen directamente al programa y, por lo tanto, si se adora a LOC como una especie de dios, entonces estas líneas de aclaración están en grave peligro de ser podadas para una victoria rápida y algunos elogios equivocados de la gerencia.

Creo que eres lo suficientemente inteligente como para darte cuenta de esto, de hecho, ese es prácticamente el objetivo de tu pregunta original. El problema no es su comprensión de cuándo la reducción de código es buena y cuándo no lo es, el problema es el dogmatismo en la aplicación indiscriminada de lo que normalmente es una práctica razonable.

Recomendaría tomarse el tiempo para conversar con su gerencia, explicar su posición y por qué siente que lo que se le pide que haga dañe el código en lugar de ayudarlo. Trate de evitar ser confrontativo, pero trate de permanecer racional y tranquilo durante esa discusión. Es importante que su gerencia comprenda 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. Las mejores prácticas están escritas en un libro, no talladas en piedra, y cuando entran en conflicto (código corto versus código legible), entonces depende del programador aplicar su juicio sobre qué mejor práctica seguir. Esperemos que sean personas razonables que aprecian aportes como este.

También debe ser un poco valiente, porque si está siendo presionado para reducir la LOC donde cree que es innecesario o inapropiado, entonces es natural que haga el cambio de todos modos por el bien de una vida tranquila. Debe resistirse a hacer esto, y debe "apropiarse" de esa decisión. En una situación en la que la gestión es razonable, no debería tener que adherirse exactamente a sus directrices, pero debería ser capaz de justificar cualquier circunstancia en la que no lo haga.

Lamentablemente, las personas pueden ser irracionales, especialmente cuando se trata de personas con un nivel jerárquico cuestionando sus decisiones y las reglas que le han impuesto. Pueden elegir no ser razonables. Necesitas estar preparado para eso también. Si puede demostrar casos en los que la mejor práctica de LOC entra en conflicto directo con otras mejores prácticas y por qué eso está dañando el producto, y si puede hacerlo en partes de la base del código en las que tuvieron poca o ninguna participación personal (por lo que no no parece un ataque personal a su trabajo o al trabajo que supervisaron), entonces esto puede ayudar a reforzar su argumento. Una vez más, debe estar preparado para justificarse de manera calmada y racional y ser capaz de "apropiarse" de los argumentos que está formulando.

Siempre que su gerencia sea gente razonable, deben apreciar que lo que usted dice tiene mérito si puede proporcionar evidencia para respaldar sus reclamos.

Creo que debería esforzarse por tener funciones con un pequeño número de SLOC.

Si LOC (líneas de código) es un número pequeño, ¿cómo afecta el código y si LOC es un número mayor, cómo afecta el código?

Idealmente, debería ser más fácil comprender 8 líneas de código de un vistazo que comprender 30.

Eso no significa que 30 LOC comprimidos en 8 líneas sean más fáciles de entender.

¿Cuál crees que es la forma correcta de hacer las cosas?

Normalmente en una función, trato de agruparlo por niveles de abstracción ("código IO aquí", "validación aquí", "cálculo aquí", etc.).

Luego, lo dividí en bloques, separados por una línea en blanco. Si el código tiene más de alrededor de diez líneas, extraigo cada bloque en una función diferente (lo hago de todos modos para el código que aparece más de una vez). He escuchado una discusión sobre cómo romper el rendimiento de esta manera (llamadas a funciones innecesarias) pero en la práctica nunca he tenido un cuello de botella de rendimiento causado por esto.

Dicho esto, he realizado funciones con esta extracción, y después de eso la función tenía ~ 40 líneas de largo (código C). Si el código está lo más agrupado posible, no veo un problema con funciones más largas.

Creo que es más importante centrarse en un código limpio y documentado automáticamente que LOC. Sin embargo, no me gusta mucho su ejemplo, porque explica lo que está haciendo el código, sin decir por qué. Por ejemplo, esto:

booleano sweet_sixteen = (edad == 16);

Es bastante redundante. Cualquiera que lea "age == 16" lo sabe. Prefiero escribir el código así:

public static boolean companyShouldThrowABigParty(int age) {
    return (age == 16) || (age == 21) || ((age > 21) && (((age % 10) == 0) || ((age % 25) == 0))); 
}

public static void happyBirthday(int age)
{  
    System.out.println(companyShouldThrowABigParty(age) ? "Super special party, this year!" : "One year older. Again.");
}

La lógica sobre decidir cuándo organizar la fiesta está separada del System.out, se puede probar y es fácil de entender. Sin embargo, lo más importante es que alguien que lee el código puede entender la razón por la que fue escrito de esa manera ("la compañía quiere organizar una gran fiesta para algunas de las personas").

Creo que menos líneas de código = más código legible

Pero, por supuesto, hay un límite cuando comienzas a minimizar / oscurecer tu código solo para obtener menos líneas.

/** Pad a number with 0 on the left */
function zeroPad(number, digits) {
    var num = number+"";
    while(num.length < digits){
        num='0'+num;
    }
    return num;
}

Esto es minificación, la lógica sigue siendo la misma, solo que menos legible. Esto no debe ser hecho por humanos, esta minificación es hecha por una máquina para ser leída por una máquina.

function zP(e,t){var n=e+"";while(n.length<t){n="0"+n}return n}

Si puede eliminar algún fragmento de código y el algoritmo sigue haciendo lo que se supone que debe hacer, continúe. Simplemente no minimice su código, hay mejores herramientas para hacerlo.

No creo que haya menos líneas de código == código más legible. Sin embargo, la realidad, que es muy diferente de la teoría, es que el código con una gran cantidad de líneas a menudo se escribe sin un diseño adecuado. En consecuencia, el requisito de menos líneas PUEDE forzar a algunos programadores a idear un mejor diseño si son capaces. El giro es que muchos programadores no lo son, entonces el requisito no ayuda mucho.

No vería el número de líneas como un problema en circunstancias normales, pero puede señalar problemas. Si alguien le muestra una clase con 1000 líneas de código, entonces algo debe estar mal con la forma en que se realizó o diseñó la clase.

Su ejemplo señala un caso en el que tiene sentido un mayor número de líneas de código. Pero ese es ese ejemplo. Todos los días veo ejemplos en los que el número de líneas está asociado a la falta de planificación

Creo que LOC es una medida mucho más útil al comienzo de un proyecto que durante la implementación real. Conocer el LOC por punto de función le permite estimar el esfuerzo del proyecto y, a partir de ahí, cuánto tiempo llevará el proyecto y la cantidad óptima de desarrolladores.

También puede influir en el diseño y la elección del idioma: reducir los puntos de función o cambiar a un idioma con un LOC / FP más bajo debería reducir el esfuerzo del proyecto, todo lo demás es igual.

Las líneas de código en sí mismas no son muy importantes. Una forma de verlo es compararlo con la prosa. La primera constatación es que una propiedad importante tanto del código como de la prosa (suponiendo que sea correcta) es la legibilidad. La legibilidad (y la comprensibilidad) ayudan con otras propiedades, como la mantenibilidad y la corrección.

Hay ventajas de poder ajustar una función en un pequeño número de líneas. Pero tener texto sin párrafos reduce su legibilidad. El uso de conceptos difíciles, palabras difíciles (raras) y formas complejas de expresión generalmente reduce la cantidad de palabras necesarias para expresar una idea, pero al mismo tiempo mueve el nivel de lectura del texto desde el nivel de escuela secundaria hasta académicos profesionales (en el caso de prosa).

En general, es útil agregar abstracciones en su código y usar ayudantes, etc. pero nuevamente, esas abstracciones pueden volverse demasiado numerosas. Lo que también puede suceder es que mueva la complejidad a otra parte del código. A veces, como cuando usted como experto está diseñando un marco / biblioteca para uso de programadores junior (o estudiantes), es una buena idea hacer esto. Pero no espere que los juniors puedan entender cómo funciona su código, simplemente haga que sea muy difícil para ellos usarlo incorrectamente.

Al escribir código, especialmente no evite agregar líneas vacías en su código. Funcionan como párrafos y lo ayudan a separar diferentes partes de su función (incluso si aún no se deben poner en ayudantes).

El gran problema con cada método formal de evaluación de código es que seguramente fallará en algún código. Esto se debe a que la programación es un tipo de arte y, como tal, no puede existir estándares claros para la evaluación. Por supuesto, hay diferentes tipos de artes: también existe la producción en masa de pinturas, y tal vez en este negocio es importante la cantidad de pintura que se gasta en una pintura. :)

Para ser sincero, no me importa mucho la medición LOC. Claro, es bueno que una función o procedimiento sea lo más breve posible, pero tomo un código legible en cualquier momento del día.

Estoy de acuerdo en que siempre requerir la reducción de LOC conduciría a un código difícil de leer.

Sin embargo, tal vez su estilo de codificación sea demasiado detallado y su revisor piense que una forma más concisa es mejor. Por ejemplo, un comentario que solo explica una afirmación que es bastante obvia gracias a la clara elección de nombres de variables es inútil.

Solo hay una cosa que miden las líneas de código y es la cantidad de líneas de código que tiene. Todo lo demás es aire caliente, especulación y prejuicio.

Hay muchos ejemplos excelentes en las otras respuestas de cómo tener menos líneas de código puede empeorar algo, no mejorarlo, pero parece que se perdió un punto central, y es: cuántas líneas realmente necesita para hacer este trabajo ?

Si llevar a cabo su tarea necesita 10 líneas de código, hágalo en 10 líneas. Si para lograrlo se necesitan 10,000 líneas, entonces, así sea, lo haces en 10,000 líneas. El culto a "menos líneas de código" no mejorará este último ejemplo si lo hace en 1,000 o 2,000 o lo que sea. El trabajo necesitaba 10,000 líneas y esas 10,000 líneas pueden incluir capas de validación, verificación de errores, seguridad, etc. que se perderían si lo hiciera en menos.

Editar

Dado que esto ha cosechado algunos votos negativos, creo que necesito ser más específico sobre lo que digo aquí. Lo primero que debe hacer cualquiera es leer esto : el punto que le pido que elimine es que el código de alto nivel que escribe puede tener poca o ninguna semejanza con el código de máquina que realmente se ejecuta. La relevancia de este punto es que un enfoque en el código de alto nivel sin una comprensión de lo que realmente sucede debajo está equivocado.

Ahora considere lo siguiente:

• Es posible escribir código muy malo y lento con una sola línea: tenga en cuenta el comentario sobre el operador ternario al final del enlace que proporcioné.

• Si una línea de código realiza una llamada API (u otra llamada a una biblioteca externa), entonces, por definición, tiene poco control directo sobre lo que se ejecuta o lo eficiente que es.

• La comprobación de errores, la limpieza, etc., todos agregan líneas de código adicionales y estoy bastante seguro de que incluso el fanático más ardiente de menos líneas de código no argumentaría en contra de ellos .

Entonces, las líneas de código son una métrica rota. Menos líneas de código no garantiza un rendimiento adicional: esa llamada de API o biblioteca es una línea y puede estar fuera de su control. Menos líneas de código no garantizan una robustez adicional: la comprobación de errores y la limpieza siempre requerirán líneas adicionales. Menos líneas de código ni siquiera garantizan una legibilidad o facilidad de mantenimiento adicionales: solo necesita mirar el IOCCC para saberlo.

Entonces, ¿qué garantiza menos líneas de código? Menos líneas de código, eso es todo.

Es profundamente incorrecto centrarse en hacer el mismo trabajo en 2.000 líneas frente a 10.000. En su lugar, enfóquese en el código que funciona, que es robusto, que funciona dentro de las tolerancias aceptadas y que es más fácil de leer y mantener en el futuro. A veces eso significa que puede hacerlo en un recuento de LoC bajo, a veces significa que debe hacerlo en un recuento de LoC más alto, pero el recuento de LoC no debería ser lo importante aquí.

¿Qué tan importante es reducir la cantidad de líneas en el código? En la mayoría de los casos, en absoluto. De hecho, en la mayoría de los casos, es más importante aumentar el número de líneas de código dividiendo las operaciones complejas en pasos más legibles, comentando cada paso y agregando comentarios en general para que el código sea más legible y extensible para otros desarrolladores que vienen después de ti.

En un período anterior, se suponía que si el número de líneas de código que es loc es grande, entonces el código es efectivo y cumple todas las tareas que solía hacer, pero se dio cuenta después de un tiempo que menos es el loc más. tiene la eficiencia ya que el costo incurrido por el sistema en la ejecución del código es muy menor. Por lo tanto, para el mejoramiento de la loc del sistema se hizo menos. Desde entonces se supuso que la loc debería ser menor. Para reducirlo, los siguientes factores deberia ser tomado en un cuenta.

1. Haz un diagrama de flujo de tu problema
2. Intenta usar menos bucles como puedas
3. Las llamadas a funciones no deberían ser demasiado
4. Se deben usar nuevas estructuras de datos como TRIE en el caso de que se use stack o queue para almacenar la información relevante.
5. Y trate de resolver el problema con un enfoque realista en lugar de uno imaginativo en el que esté almacenando una gran cantidad de números en una matriz muy grande y luego intente acceder a ella a través de la matriz.]
6. Utilice tantas macros como sea posible. Además, el enfoque a utilizar también depende del problema. Si es realmente complejo, a veces usar el enfoque simple también es equivalente al complejo.