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

Medindo o SLOC (que é efetivamente o que suas revisões estão fazendo), torna o SLOC importante ... O SLOC é importante? - absolutamente não, nunca foi (Fora Concursos de programação ofuscados ), nunca estará em uma organização comercial.

Pergunte a si mesmo uma pergunta simples - como "Reduzir o SLOC dessa rotina" torna o código anyones melhor. O que provavelmente está acontecendo nesse 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 o 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 em seu código é uma responsabilidade técnica - é um potencial ponto de falha. Se você escrever um método com 10 declarações e seu colega de trabalho escrever um que obtenha a mesma funcionalidade com 5 declaraçõ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, complexa ou problemática).

Aqui está o asterisco. Não é sobre o 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();
}

Esta é uma linha de código, mas é um lugar onde uma quantidade incrível de coisas pode dar errado. Então eu diria que se concentrar em fazer o máximo com o menor número de instruções - escreva o código que você precisa para fazer as coisas e não mais. Pelo menos, acho que isso é o que seus revisores de código estão fazendo.

Pessoalmente, acho que há um equilíbrio a ser atingido. Como eu disse, cada afirmação que você escreve é uma desvantagem, mas se puxar uma variável local com um nome descritivo torna seu método muito mais claro e legível, então há um caso a ser feito para isso também. Acho que você pode facilmente entrar em situações em que as pessoas estão criticando diferenças estéticas relativamente pequenas, mas, no geral, acho que seus revisores têm a ideia certa - favorecer a minimização do número de coisas que podem dar errado.

Seguir o conselho dos revisores, literalmente, não vai adiantar nada, porque o resultado direto óbvio é a promoção de concisos (limite de tamanho de linha, não obstante). Acredito que a lição a ser aprendida aqui, no entanto, é fazer seu código fazer menos coisas .

Em outras palavras, este é um apelo à simplicidade. É bastante popular alegação de que código é um passivo, não um ativo , então reduzir seu valor preservando a funcionalidade é um esforço nobre. Isso pode ser alcançado por uma abordagem direta e mais realista, que lide diretamente com o problema e prefira soluções concisas.

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

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

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

Atualmente, trabalho como desenvolvedor sênior de aplicativos 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 pode ser, melhor, MAS não ao custo de poder analisar e corrigir rapidamente (ou adicionar) a ele. Para mim, quando você está encarregado de aplicações críticas de negócios que precisam ter um vasto nível de escalabilidade e capacidade de alterações dinâmicas em um ambiente sem interrupções, o código conciso e fácil de ler é um dos elementos mais importantes no desenvolvimento. . A crédito da resposta de Erik Dietrich , esta:

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 alterando todas as empresas do código existente:

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.

Quanto a como isso afeta o código? Eu nunca notei um aumento ou diminuição de desempenho de, digamos, 100 linhas de código. O simples 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 vi alguns processos escritos muito condensados, porém ineficientes, com desempenho diferente dos códigos mais longos com melhor fluxo de código.

IMO, é uma má ideia medir a eficácia do código por meio de uma contagem de LOC trivial. Há muito mais para o que faz código corretamente projetado e eficaz.

Na minha experiência, código efetivo:

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

Há muitas respostas aqui que abordam os prós e contras técnicos de manter o LOC baixo e se é ou não uma métrica de software de qualidade significativa. Não é sobre isso que esta questão é. O que é sobre como lidar com a administração que insiste em uma aderência dogmática ingênua a uma regra de codificação específica.

A intenção de conselhos sobre manter o LOC down é evitar a criação de métodos que tentem fazer muito de uma só vez, e desencorajar a criação de "classes de deus", que sabem muito sobre aspectos de um design que não são sua 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 para contagens baixas de LOC (pequenos métodos se encaixam em sua cabeça mais facilmente do que os grandes, menos coisas no código significam menos coisas para dar errado, etc.), mas também estão sujeitos à lei de retornos decrescentes. . Refatorar um método de 150 linhas em um número de 20 métodos de linha é 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 alguma outra faceta do bom design de software (como legibilidade), você chegou a um ponto em que pode justificar que você não o faça. Remover variáveis que contextualizam o significado do código e substituí-las por literais que não o fazem é algo muito ruim de se fazer. Um bom código quase não possui 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 LOC estiver sendo adorado como algum tipo de deus, tais linhas de esclarecimento estarão em grande risco de serem eliminadas para uma rápida vitória. alguns elogios equivocados da administração.

Eu acredito que você é inteligente o suficiente para perceber isso, na verdade, é basicamente o impulso da sua pergunta original. O problema não é sua compreensão de quando a redução do código é boa e quando não é, o problema é o dogmatismo em 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 conflituoso, 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 sobre práticas recomendadas só é útil se aplicado de forma pragmática. A melhor prática é escrita em um livro, não gravada em pedra, e quando está em conflito (código curto versus código legível), cabe ao programador aplicar seu julgamento sobre qual melhor prática seguir. Espero que eles sejam pessoas razoáveis que apreciam informações como essa.

Você também precisa ser um pouco corajoso, porque se você está sendo pressionado a reduzir o LOC onde você acha que é desnecessário ou inadequado, então é natural que você faça a mudança de qualquer forma por uma vida tranquila. Você precisa resistir a fazer isso, e você tem que "possuir" essa decisão. Em uma situação em que o gerenciamento é razoável, você não deveria aderir exatamente às suas diretrizes, mas deve ser capaz de justificar quaisquer circunstâncias em que não o faça.

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

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

If LOC (lines of code) is a small number, how does it effect the code and if LOC is a larger number, how does it effect the code ?

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

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

What do you think is the right way of doing things.

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-o em blocos, separados por uma linha em branco. Se o código é mais do que cerca de dez linhas, eu extrai cada bloco em uma função diferente (eu faço isso de qualquer maneira para o código que aparece mais de uma vez). Eu ouvi uma discussão sobre quebrar o desempenho dessa maneira (chamadas de função desnecessárias), mas na prática eu nunca tive um gargalo de desempenho causado por isso.

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

Acho mais importante focar no código limpo e documentado automaticamente do que no LOC. Eu realmente não gosto do seu exemplo, porque explica o que o código está fazendo, sem dizer por quê. Por exemplo, isso:

booleano sweet_sixteen = (idade == 16);

é bastante redundante. Qualquer pessoa que esteja lendo "age == 16" sabe disso. Eu preferiria 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 de decidir quando lançar a parte é separada do System.out, pode ser testada e é fácil de entender. Mais importante, porém, alguém lendo o código pode entender a razão pela qual foi escrito dessa forma ("a empresa quer dar uma grande festa para algumas pessoas").

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

Mas, claro, há algum limite quando você começa a minimizar / obscurecer 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;
}

Esta é a minimização da 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 pedaço de código, e o algoritmo ainda está fazendo o que deveria, ok, vá em frente. Apenas não minimize seu código, existem ferramentas melhores para fazer isso.

Eu não acho 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 criarem um design melhor se forem capazes. A diferença é que muitos programadores não são, então a exigência não ajuda muito.

Eu não vejo o número de linhas como um problema em circunstâncias normais, mas isso pode apontar para problemas. Se alguém mostrar uma classe com 1000 linhas de código, algo deve estar errado com a maneira como a aula foi feita 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á ligado à 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. Conhecendo o LOC por ponto de função permite estimar o esforço do projeto e, a partir disso, quanto tempo o projeto levará e o número ideal de desenvolvedores.

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

Linhas de código em si não são muito importantes. Uma maneira de ver isso é compará-lo com a prosa. A primeira realização é que uma propriedade importante do código e da prosa (assumindo a correção) é a legibilidade. Legibilidade (e inteligibilidade) ajuda com outras propriedades, como manutenção e correção.

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

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

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

O grande problema com todo método formal de avaliação de código é que ele certamente falhará em algum código. Isso ocorre porque a programação é uma espécie de arte e, como tal, não há padrões claros para a avaliação. É claro que existem diferentes tipos de artes - a produção em massa de pinturas também existe, e talvez nesse negócio seja importante a quantidade de tinta usada em uma pintura. :)

Para ser perfeitamente honesto, eu 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 eu tomo código legível em curto a qualquer hora do dia.

Concordo que sempre exigir redução de 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 apenas explica uma afirmação que é 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ê tem. Todo o resto é ar quente, especulação e preconceito.

Existem muitos bons exemplos 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 perdido, e isso é: quantas linhas você realmente precisa para fazer este trabalho?

Se realizar sua tarefa precisa de 10 linhas de código, então faça isso em 10 linhas. Se conseguir isso precisa de 10.000 linhas, então, do mesmo modo, faça isso em 10.000 linhas. O culto de "menos linhas de código" não tornará o último exemplo melhor se você fizer isso em 1.000 ou 2.000 ou qualquer outra coisa. O trabalho precisava 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ê fizesse isso em menos.

Editar

Como isso gerou 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 este

Agora considere o seguinte:

• É possível escrever códigos muito ruins e lentos com apenas uma única linha - observe o comentário sobre o operador ternário no final do link que forneci.

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

• Verificação de erros, limpeza, etc, todos adicionam linhas extras de código e estou certo de que até mesmo o mais ardente fã de menos linhas de código não argumentaria contra aqueles .

Então - as linhas de código são 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 do seu controle. Menos linhas de código não garantem robustez extra - a verificação de erros e a limpeza sempre exigirão linhas extras. Um número menor de linhas de código nem sequer garante maior capacidade de leitura ou manutenção - você só precisa olhar para o IOCCC para saber disso.

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

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

Qual a importância de reduzir o número de linhas no código? Na maioria dos casos, não em todos. Na verdade, na maioria dos casos, é mais importante aumentar o número de linhas de código dividindo as operações complexas em etapas mais legíveis e comentando cada etapa, além de adicionar comentários em geral para tornar o código mais legível e extensível por outros. desenvolvedores que vêm atrás de você.

No período anterior, assumiu-se que se o número de linhas de código que é loc é grande, então o código é efetivo e realiza todas as tarefas que ele é usado, mas foi percebido depois de algum tempo que menos é o mais ainda tem a eficiência como o custo incorrido pelo sistema em executar o código é muito menos.Assim para o betterment do sistema o loc era ser feito menos. Desde então foi supor que o lugar deve ser menos. Para reduzi-lo os seguintes fatores devem ser levados em conta.

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