Quão importante é reduzir o número de linhas no código?

Sou desenvolvedor de software que trabalha em J2SE (java principal).
Freqüentemente, durante nossas revisões de código, somos solicitados a reduzir o número de linhas em nosso código.

Não se trata de remover código redundante, é seguir um estilo que se concentra em fazer as mesmas coisas com menos linhas no código, enquanto acredito em ter clareza no código, mesmo que isso signifique aumentar o número de linhas.

O que você acha que é a maneira correta de fazer as coisas?
Se LOC (linhas de código) é um número pequeno, como isso afeta o código? Se LOC é um número maior, como isso afeta o código?

exemplo do site: "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.");
    }
}

O problema com as medições, não importa quão bem-intencionadas elas sejam, é o próprio ato de medir o item que o torna importante, e o corolário, o ato de não medir um item o torna sem importância. É absolutamente essencial medir o que é importante, e não o que não é importante.

Medir o SLOC (que é efetivamente o que suas avaliações estão fazendo) torna o SLOC importante ... O SLOC é importante? - absolutamente não, nunca esteve ( concursos de programação fora do ofuscamento ), nunca estará em uma organização comercial.

Faça a si mesmo uma pergunta simples - como "Reduzir o SLOC dessa rotina" torna o código de alguém melhor. O que provavelmente está acontecendo neste caso é que o SLOC está sendo usado como uma maneira ingênua de medir a complexidade. O que você deve evitar a todo custo é contar os feijões fáceis de contar - medidas objetivas, como SLOC, em vez de contar as importantes, mas difíceis de contar - por exemplo, legibilidade, complexidade etc.

Concordo com seus revisores de código, mas com um asterisco. Cada declaração que você escreve no seu código é uma responsabilidade técnica - é um possível ponto de falha. Se você escreve um método com 10 instruções e seu colega de trabalho escreve um que alcança a mesma funcionalidade com 5 instruções, é provável que ele seja 'melhor' conforme medido pela probabilidade de problemas (há duas vezes mais lugares em que seu código pode estar errado, excessivamente complexo ou problemático).

Aqui está o asterisco, no entanto. Não se trata do número real de linhas de código na ideia, porque você pode reduzir o número de linhas com algo como:

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

Essa é uma linha de código, mas é um lugar onde uma quantidade incrível de coisas pode dar errado. Então, eu diria que o foco é fazer o máximo possível com o menor número de instruções - escreva o código necessário para concluir as tarefas e não mais. Pelo menos, acho que é para isso que seus revisores de código estão dirigindo.

Pessoalmente, acho que há um equilíbrio a ser atingido. Como eu disse, cada declaração que você escreve é ​​um passivo, mas se extrair uma variável local com um nome descritivo tornar seu método muito mais claro e legível, também haverá um caso a ser feito. Eu acho que você pode facilmente entrar em situações em que as pessoas estão discutindo sobre diferenças estéticas relativamente pequenas, mas no geral, acho que seus revisores têm a idéia certa - favorecem minimizar o número de coisas que podem dar errado.

Seguir o conselho dos revisores literalmente não fará nenhum bem, porque o resultado direto óbvio é a promoção de uma linha concisa (apesar do limite de comprimento da linha). Porém, acredito que a lição a ser aprendida aqui é fazer com que seu código faça menos coisas .

Em outras palavras, este é um pedido de simplicidade. É uma afirmação bastante popular que o código é um passivo, não um ativo , portanto, reduzir seu valor e preservar a funcionalidade é um esforço nobre. Isso pode ser conseguido por uma abordagem direta e mais prática que lida diretamente com o problema e prefere soluções concisas.

Como Ken Thompson disse uma vez: Um dos meus dias mais produtivos foi jogar fora 1000 linhas de código .

Costumo concordar com sua posição de "ter clareza no código, mesmo que isso signifique aumentar o número de linhas".

Eu já vi muitas frases simples que são bastante concisas, mas não é imediatamente aparente o que elas estão fazendo. A legibilidade é fundamental, já que outros desenvolvedores terão que manter seu código.

Eu argumentaria que uma coisa melhor a se procurar são métodos curtos. Não é curto por causa de poucas linhas de código, mas curto porque eles fazem uma única coisa.

Atualmente, trabalho como desenvolvedor de aplicativos sênior e analista de negócios de projetos para uma grande empresa e nunca a contagem de linhas do meu desenvolvimento foi um centro de interesse. No entanto, acredito que, quanto mais condensado um código puder ser, melhor, MAS não com o custo de poder analisá-lo e corrigi-lo rapidamente (ou adicionar). Para mim, quando você é responsável por aplicativos críticos para os negócios que DEVEM ter um vasto nível de escalabilidade e capazes de realizar alterações dinâmicas em um ambiente de mudanças sem interrupções, o código conciso e fácil de ler é um dos elementos mais importantes no desenvolvimento . Para o crédito da resposta de Erik Dietrich , isto:

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

seria completamente inaceitável para mim, no entanto, achei que alterar todos os códigos existentes das empresas de:

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

para:

value.prop =  boolean ? option1 : option2;

foi uma excelente opção de condensação de código que não sacrifica a legibilidade.

Na medida em que isso afeta o código? Eu nunca notei um aumento ou diminuição no desempenho de, digamos, 100 linhas de código. O fato é que é mais o processo que você utiliza para chegar ao produto final do que o número de linhas necessárias para chegar lá. Eu já vi alguns processos escritos muito condensados, porém ineficientes, executam diferentemente de códigos mais longos com melhor fluxo de código.

Na IMO, é uma má idéia medir a eficácia do código por uma contagem LOC trivial. Há muito mais sobre o que torna um código adequadamente projetado e eficaz.

Na minha experiência, código eficaz:

• não quebra nenhum dos princípios do SOLID
• é legível e auto-explicativo
• passa no teste de simplicidade de Albert Einstein: "Tudo deve ser feito o mais simples possível, mas não mais simples".

Aqui existem muitas respostas que abordam os prós e contras técnicos de manter o LOC em baixa e se é uma métrica de software de qualidade significativa. Não é disso que se trata esta questão. O que se trata é como lidar com a gerência que insiste em uma aderência dogmática ingênua a uma regra de codificação específica.

Infelizmente, é bastante comum as pessoas se prenderem a coisas que são boas recomendações quando usadas no contexto apropriado e aplicadas de forma pragmática, tiram-nas desse contexto e as aplicam dogmaticamente enquanto não apreciam os problemas que as orientações existem para atenuar em primeiro lugar .

A intenção do conselho em manter o LOC baixo é evitar a criação de métodos que tentam fazer demais de uma só vez e desencorajar a criação de "classes divinas", que sabem muito sobre aspectos de um design que não são seus. responsabilidade direta e da qual todas as outras classes do sistema dependem. Outra vantagem do código mais curto é que ele é mais legível, embora, como você apontou, você possa exagerar até o ponto em que a legibilidade realmente começa a sofrer.

Existem vantagens óbvias nas contagens baixas de LOC (métodos pequenos cabem na sua cabeça com mais facilidade do que os grandes, menos coisas no código significam menos coisas para dar errado etc.), mas também estão sujeitas à lei dos retornos decrescentes. Refatorar um método de 150 linhas em vários métodos de 20 linhas é uma vitória muito maior do que refatorar um método de 10 linhas em um método de 7 linhas.

Quando essa refatoração ocorre às custas de outras facetas do bom design de software (como legibilidade), você chega a um ponto em que pode justificar não fazê-lo. Remover variáveis ​​que dão contexto ao que o código significa e substituí-las por literais que não o fazem é uma coisa muito muito ruim a se fazer. Bom código quase não tem literais. No entanto, essas variáveis ​​(e constantes nomeadas) são linhas de código que não contribuem diretamente para o programa e, portanto, se o LOC está sendo adorado como algum tipo de deus, essas linhas de esclarecimento correm grande risco de serem podadas para uma rápida vitória e alguns elogios equivocados da administração.

Acredito que você é inteligente o suficiente para perceber isso, na verdade esse é basicamente o impulso da sua pergunta original. O problema não é o seu entendimento de quando a redução de código é boa e, quando não é, o problema é o dogmatismo ao aplicar o que normalmente é uma prática razoável indiscriminadamente.

Eu recomendaria reservar um tempo para conversar com sua gerência, explicando sua posição e por que você acha que o que está sendo solicitado a fazer prejudica o código, em vez de ajudá-lo. Tente evitar ser confrontador, mas tente permanecer racional e calmo durante essa discussão. É importante que sua gerência entenda que a programação é uma atividade pragmática, e o aconselhamento de melhores práticas só será útil se for aplicado de maneira pragmática. A melhor prática é escrita em um livro, não gravada em pedra, e quando ela entra em conflito (código curto versus código legível), cabe ao programador aplicar seu julgamento sobre qual a melhor prática a seguir. Espero que sejam pessoas razoáveis ​​que apreciem contribuições como essa.

Você também precisa ser um pouco corajoso, porque se você está sendo pressionado a reduzir o LOC, onde acha desnecessário ou inapropriado, é natural que você faça a alteração de qualquer maneira por uma vida tranquila. Você precisa resistir a fazer isso e precisa "tomar posse" dessa decisão. Em uma situação em que a administração é razoável, você não precisa seguir exatamente as diretrizes, mas deve justificar as circunstâncias em que não o faz.

Infelizmente, as pessoas podem ser irracionais, especialmente quando se trata de pessoas com menos hierarquia questionando suas decisões e as regras que elas impuseram a você. Eles podem optar por não ser razoáveis. Você precisa estar preparado para isso também. Se você pode demonstrar casos em que a melhor prática do LOC entra em conflito direto com outras práticas recomendadas e por que isso está prejudicando o produto, e se você pode fazê-lo em partes da base de código para as quais eles tiveram pouco ou nenhum envolvimento pessoal (por isso não parece um ataque pessoal ao trabalho deles ou ao trabalho que eles supervisionaram); isso pode ajudar a reforçar seu argumento. Novamente, você deve estar preparado para justificar-se de uma maneira calma e racional e ser capaz de "possuir" os argumentos que está fazendo.

Desde que sua gerência seja uma pessoa razoável, eles devem entender que o que você está dizendo tem mérito se você puder fornecer evidências para apoiar suas reivindicações.

Eu acho que você realmente deve se esforçar para ter funções com um pequeno número de SLOC.

Se LOC (linhas de código) é um número pequeno, como isso afeta o código e se LOC é um número maior, como isso afeta o código?

Idealmente, deve ser mais fácil entender 8 linhas de código rapidamente do que entender 30.

Isso não significa que 30 LOC compactados em 8 linhas serão mais fáceis de entender.

O que você acha que é a maneira certa de fazer as coisas?

Normalmente, em uma função, tento agrupá-la por níveis de abstração ("código de E / S aqui", "validação aqui", "computação aqui" e assim por diante).

Depois, divido em blocos, separados por uma linha em branco. Se o código tiver mais de dez linhas, extrairei cada bloco em uma função diferente (faço isso de qualquer maneira para o código que aparece mais de uma vez). Ouvi um argumento sobre a quebra de desempenho dessa maneira (chamadas de função desnecessárias), mas na prática nunca tive um gargalo de desempenho causado por isso.

Dito isto, eu tive funções com essa extração concluída e, depois disso, a função tinha ~ 40 linhas de comprimento (código C). Se o código estiver o mais agrupado possível, não vejo problema com funções mais longas.

Eu acho que é mais importante focar em código limpo e documentado automaticamente, do que LOC. Eu realmente não gosto do seu exemplo, no entanto, porque explica o que o código está fazendo, sem dizer o porquê. Por exemplo, isto:

boolean sweet_sixteen = (idade == 16);

é bastante redundante. Qualquer pessoa que esteja lendo "age == 16" sabe disso. Prefiro escrever o código assim:

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.");
}

A lógica sobre como decidir quando dar a festa é separada do System.out, pode ser testada e é fácil de entender. Mais importante, porém, alguém que lê o código pode entender o motivo pelo qual foi escrito dessa maneira ("a empresa quer dar uma grande festa para algumas pessoas").

Eu acho que menos linhas de código = código mais legível

Mas é claro que há algum limite quando você começa a minificar / ocultar seu código apenas para obter menos linhas.

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

Isso é minificação, a lógica permanece a mesma, apenas menos legível. Isso não deve ser feito por humanos, essa minificação é feita por máquina para ser lida por uma máquina.

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

Se você pode remover algum trecho de código, e o algoritmo ainda está fazendo o que deve fazer, ok, vá em frente. Apenas não minimize seu código, existem ferramentas melhores para fazer isso.

Eu não acho que menos linhas de código == código mais legível. No entanto, a realidade, que é muito diferente da teoria, é que o código com grande número de linhas geralmente é escrito sem um design adequado. Conseqüentemente, a exigência de menos linhas PODE forçar alguns programadores a criar um design melhor, se forem capazes. A desvantagem é que muitos programadores não são, então o requisito não ajuda muito.

Eu não veria o número de linhas como um problema em circunstâncias normais, mas isso pode apontar para problemas. Se alguém lhe mostrar uma classe com 1000 linhas de código, algo deve estar errado com a maneira como a classe foi criada ou projetada.

Seu exemplo aponta para um caso em que um número maior de linhas de código faz sentido. Mas esse é esse exemplo. Todos os dias vejo exemplos em que o número de linhas está associado à falta de planejamento

LOC é uma métrica muito mais útil no início de um projeto do que durante a implementação real, eu acho. Conhecer o LOC por ponto de função permite estimar o esforço do projeto e, a partir daí , quanto tempo o projeto levará e o número ideal de desenvolvedores.

Também pode influenciar a escolha do design e do idioma: reduzir os pontos de função ou mudar para um idioma com um LOC / FP menor deve reduzir o esforço do projeto, sendo o restante igual.

As próprias linhas de código não são muito importantes. Uma maneira de ver isso é compará-lo com a prosa. A primeira percepção é que uma propriedade importante do código e da prosa (assumindo a correção) é a legibilidade. A legibilidade (e a compreensibilidade) ajudam com outras propriedades, como manutenção e correção.

Há vantagens em poder ajustar uma função em um pequeno número de linhas. Mas ter texto sem parágrafos reduz sua legibilidade. Usando conceitos difíceis, palavras difíceis (raras) e formas complexas de expressão geralmente reduzem a quantidade de palavras necessárias para expressar uma ideia, mas, ao mesmo tempo, move o nível de leitura do texto do ensino médio para os acadêmicos profissionais (no caso de prosa).

Em geral, é útil adicionar abstrações no seu código e usar ajudantes etc., mas novamente, essas abstrações podem se tornar muito numerosas. O que também pode acontecer é que mova a complexidade para outra parte do código. Às vezes, como quando você, como especialista, está projetando uma estrutura / biblioteca para uso de programadores juniores (ou estudantes), é uma boa idéia fazer isso. Mas não espere que os juniores consigam entender como seu código funciona, apenas dificulte o uso incorreto.

Ao escrever um código, principalmente, evite adicionar linhas vazias ao seu código. Eles funcionam como parágrafos e ajudam a separar diferentes partes de sua função (mesmo que ainda não devam ser colocadas em auxiliares).

O grande problema de todo método formal de avaliação de código é que certamente falhará em algum código. Isso ocorre porque a programação é um tipo de arte e, como tal, não pode haver padrões claros para avaliação. É claro que existem diferentes tipos de arte - a produção em massa de pinturas também existe, e talvez nesse ramo seja importante a quantidade de tinta gasta em uma pintura. :)

Para ser perfeitamente honesto, não dou a mínima para a medição de LOC. Claro, é bom que uma função ou procedimento seja o mais curto possível, mas tomo código legível em curto a qualquer hora do dia.

Concordo que sempre exigir redução do LOC levaria a um código difícil de ler.

No entanto, talvez seu estilo de codificação seja muito detalhado e seu revisor pense que uma maneira mais concisa é melhor. Por exemplo, um comentário que explica apenas uma afirmação bastante óbvia, graças à escolha clara de nomes de variáveis, é inútil.

Há apenas uma coisa que as linhas de código medem e esse é o número de linhas de código que você possui. Tudo o resto é ar quente, especulação e preconceito.

Existem muitos exemplos excelentes nas outras respostas de como ter menos linhas de código pode tornar algo pior, não melhor, mas um ponto central parece ter sido esquecido, e é isso: quantas linhas você realmente precisa para fazer esse trabalho ?

Se a sua tarefa precisa de 10 linhas de código, faça-o em 10 linhas. Se você precisa de 10.000 linhas, da mesma forma, faça-o em 10.000 linhas. O culto a "menos linhas de código" não melhorará o último exemplo se você fizer isso em 1.000 ou 2.000 ou o que for. O trabalho precisava de 10.000 linhas e essas 10.000 linhas podem incluir camadas de validação, verificação de erros, segurança etc., que seriam perdidas se você o fizesse em menos.

Editar

Como isso já recebeu alguns votos negativos, acho que preciso ser mais específico sobre o que estou dizendo aqui. A primeira coisa que alguém deve fazer é ler isso - o ponto que estou pedindo para você tirar isso é que o código de alto nível que você escreve pode ter pouca ou nenhuma semelhança com o código de máquina que realmente é executado. A relevância desse ponto é que o foco no código de alto nível sem a compreensão do que realmente acontece por baixo é equivocado.

Agora considere o seguinte:

• É possível escrever código lento e muito ruim com apenas uma linha - observe o comentário no operador ternário no final do link que forneci.

• Se uma linha de código faz uma chamada de API (ou outra chamada em uma biblioteca externa), você tem, por definição, pouco em termos de controle direto sobre o que é executado ou a eficiência.

• A verificação de erros, a limpeza etc. adicionam linhas de código extras e tenho certeza de que mesmo o fã mais ardente de menos linhas de código não argumentaria contra elas .

Então - linhas de código é uma métrica quebrada. Menos linhas de código não garantem desempenho extra - essa chamada de API ou biblioteca é uma linha e pode estar fora de seu controle. Menos linhas de código não garantem robustez extra - a verificação e a limpeza de erros sempre exigem linhas extras. Menos linhas de código nem garantem legibilidade ou manutenção extra - você só precisa consultar a IOCCC para saber disso.

Então, o que menos linhas de código garantem? Menos linhas de código, só isso.

É profundamente errado se concentrar em fazer o mesmo trabalho em 2.000 linhas versus em 10.000. Em vez disso, concentre-se no código que funciona, que é robusto, que executa dentro das tolerâncias aceitas e que é mais fácil de ler e manter no futuro. Às vezes, isso significa que você pode fazê-lo em uma contagem baixa de LoC, às vezes significa que você deve fazê-lo em uma contagem mais alta de LoC, mas a contagem de LoC não deve ser o que é importante aqui.

Quão importante é reduzir o número de linhas no código? Na maioria dos casos, nem um pouco. De fato, na maioria dos casos, é mais importante aumentar o número de linhas de código dividindo operações complexas em etapas mais legíveis, comentando cada etapa e adicionando comentários em geral para tornar o código mais legível e extensível por outras desenvolvedores que vêm atrás de você.

No período anterior, assumiu-se que, se o número de linhas de código loc for grande, o código será efetivo e realizará todas as tarefas para as quais está acostumado a realizar, mas foi percebido após algum tempo que menos é o loc mais tem a eficiência, pois o custo incorrido pelo sistema na execução do código é muito menor. Assim, para melhorar o local do sistema, seria menor. Desde então, assumiu-se que o local deveria ser menor. Para reduzi-lo, os seguintes fatores deve ser levado em consideração.

1. Faça um fluxograma do seu problema
2. Tente usar menos número de loops possível
3. As chamadas de função não devem ser muito
4. Novas estruturas de dados como TRIE devem ser usadas no caso em que a pilha ou fila é usada para armazenar as informações relevantes.
5. E tente resolver o problema com uma abordagem realista, em vez de imaginativa, na qual você armazena uma quantidade enorme de números em uma matriz muito grande e tenta acessá-la através da matriz.]
6. Use o maior número possível de macros Além disso, a abordagem a ser usada também depende do problema. Se for realmente complexo, às vezes o uso da abordagem simples também é equivalente à complexa.