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

85

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.");
    }
}
Ankit
fonte
63
I pode transformar qualquer arquivo java a uma única linha de código ( s/\n/ /g), isso não significa que vai ser mesmo remotamente legível
catraca aberração
6
Sua empresa usa o LOC para medir a produtividade, de modo que está tentando impedir que você 'jogue o sistema' com seus padrões de codificação?
JeffO 5/02
29
Seria realmente útil se você pudesse fornecer um pequeno exemplo de cada estilo (não escolhido de maneira diferente), para que todos saibam do que estamos falando. Existem extremos em qualquer direção; e a resposta será altamente dependente do seu contexto.
Daniel B
3
Sempre limpe seu quarto, então sua mãe entra e diz "isso não está limpo" e aponta 10 coisas que você não guardou. Isso é basicamente o que eles estão dizendo na revisão de código.
Reactgular
11
O exemplo que você deu é quase uma versão em livro da refatoração Introduce Explaining Variable , que geralmente aumenta a legibilidade e a intenção (o que é uma coisa boa). Alguns argumentam que você deve refatorar as variáveis ​​ainda mais em funções curtas de uma linha, mas isso está levando ao extremo; Eu diria que sua versão é preferida à versão curta recomendada pela revisão.
Daniel B

Respostas:

75

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.

mattnz
fonte
33
Embora a descrição da revisão pela OP pareça um pouco inútil, eu diria que as linhas de código geralmente estão relacionadas às medidas mais difíceis que você menciona. As funções longas geralmente são menos legíveis e também têm maior complexidade ciclomática. Então, realmente se resume a se a revisão está realmente recomendando a quebra / redução do código que se beneficiaria com isso, ou se está recomendando apenas a inclusão de várias linhas legítimas.
Daniel B
3
Eu diria que o motivo pelo qual é importante reduzir o número de linhas de código é poder visualizar mais funções em uma única página. Quanto mais fácil é visualizar um método ou classe sem precisar rolar, mais fácil é manter o contexto em sua cabeça.
CLandry
2
@DanielB As funções longas geralmente são mais difíceis de entender, não porque são longas; mas, porque eles tentam fazer muitas coisas ao mesmo tempo. Por exemplo, eles geralmente começam com a validação de entradas e, em seguida, com algum processamento, seguido de uma verificação para processamento alternativo, seguido de outra para verificar se algo não relacionado precisa de atualização, seguido por uma rotina embutida que não tem nada a ver com a ação principal ( como lógica de data que verifica a saturação e o ajuste do mês) e assim por diante. Quando você chega ao fim, não consegue se lembrar de qual era a responsabilidade da turma.
Edwin Buck
1
@CLandry: Manter o contexto ajustando-o em uma página é um motivo muito ruim para reduzir o SLOC. Certamente, é mais fácil manter o contexto se o código estiver bem definido e mais fácil de ler. - O que é uma "página" de 2500 ou 1000 pixels? Eu tenho um 2 * 30" monitores em modo retrato, mas às vezes desenvolvem em um laptop.
mattnz
4
Estudos que mostram (ref a) LOC === Os erros são um centavo uma dúzia. É um fato bem conhecido e aceito. O que não foi mostrado (que eu saiba) é (ref b) "Reduzir LOC em uma base de código === Reduzir Bugs nessa base de código". Extrapolar (ref a) a reivindicação (ref b) não é científico. Publicar um artigo que comprove ou refute o relacionamento seria.
mattnz
84

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.

Erik Dietrich
fonte
4
Concordo - reduzir o número de instruções pode ser útil, até um limite, no entanto, se a revisão do código estiver querendo reduzir o número de instruções, eles não diriam apenas "menor número de instruções" em vez de "menor número de linhas de instruções" código".
mattnz
1
@mattnz apenas com certeza se eles estão sendo pedantes.
Dan Neely
2
Na minha experiência, alguém que possa escrever o mesmo algoritmo em menos instruções a) usará coisas que não são muito comuns ou pouco compreendidas eb) introduzirá mais casos extremos que precisam de testes de unidade e podem apresentar bugs. Obviamente, isso pressupõe que os dois programadores são aproximadamente igualmente capazes.
Daniel AA Pelsmaeker
13
+1 para a cadeia de chamadas de função humoristicamente longa e o sorrateiro colchete duplo depois violations().
Joe Z.
5
100% +1, muitas pessoas não entendem as conseqüências de cada bit adicional de código adicionado a uma base de código, isso é algo que as pessoas realmente precisam saber.
Jimmy Hoffa
32

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 .

Xion
fonte
21

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.

jhewlett
fonte
12

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.

Joshua Volearix
fonte
Você quer dizervalue.prop = boolean ? option1 : option2;
Christoffer Hammarström
Eu faço! ... no 'código condensado' de qualquer maneira.
Joshua Volearix
2
Seu segundo exemplo é especialmente bom, porque não é apenas mais simples, mas também fica mais claro que é uma atribuição de uma das duas opções, sem efeitos colaterais. O if-then-elseobscurece isso; por exemplo, é muito fácil atribuir a uma variável diferente em cada ramo do if(o que pode ou não ser um erro, mas é difícil identificá-lo).
Andres F.
Encontrei ambientes em que o uso do operador ternário era expressamente proibido. Geralmente eles eram ambientes em transição do PL / SQL ou similares ao Java, onde as pessoas tinham medo da tersidade ... Quanto à sua afirmação de que não há impacto no desempenho ao escrever mais código, pode haver dependendo do código. Se você substituir um operador por uma chamada de método, por exemplo, definitivamente haverá um impacto (e pode ser um impacto sério).
jwenting
9

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".
dino octaviano
fonte
1
+1 para a citação de Einstein.
Justsalt
6

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.

GordonM
fonte
2

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.

utnapistim
fonte
2

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

Eduardo Scoz
fonte
2
O significado dos dezesseis anos (e com 21 anos) é específico da cultura. A frase "dezesseis anos" é mais pesquisável que "idade == 16". Por esse motivo, dar nomes a determinados booleanos pode ser útil. No entanto, concordo com o seu sentimento geral: não perca tempo explicando o código auto-explicativo.
Jonas Kölker
1

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.

Vitim.us
fonte
1

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.

zhouji
fonte
1

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

IvoC
fonte
0

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.

James Jensen
fonte
0

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).

Paul de Vrieze
fonte
-1

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. :)

johnfound
fonte
-1

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.

Vladimir Kocjancic
fonte
-2

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.

MatthieuW
fonte
5
Tanto quanto eu sei, os comentários não contam para o LOC.
FCM
1
Não conta ou conta, de acordo com a definição que você usa.
precisa
1
Comentários são comentários. Eles não são código. Portanto, eles não se aplicam às contagens LOC. Embora o código de auto-documentação seja melhor que o código bem comentado, remover comentários do código menos óbvio não é útil para ninguém.
precisa saber é o seguinte
-2

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.

mh01
fonte
1
Por definição , se uma tarefa exige absolutamente N linhas de código para ser executada (o que é algo difícil de determinar em primeiro lugar), isso não pode ser feito em menos de N linhas. Portanto, sua tarefa de 10.000 linhas não pode ser executada em 2.000, ponto final. Eu acho que o OP está falando sobre os casos em que há alguma margem de manobra, ou seja, "o requisito pode ser totalmente cumprido de qualquer maneira, então qual é o melhor?"
Andres F.
-3

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ê.

Infin8Loop
fonte
1
Por que todos os votos negativos?
Marko
Sim, por que uma resposta perfeitamente sensata foi rebaixada? Por que outras respostas perfeitamente sensatas, que desafiaram a idéia de que linhas reduzidas de código são um fim em si, também foram negadas?
Maximus Minimus
1
@ mh01 Acho que porque a maioria está errada? Especificamente, in most cases, it is more important to increase the number of lines of code by breaking out complex operations into more readable stepsnão é minha experiência. O código complexo pode, com mais freqüência, tornar-se mais legível e menos problemático, tornando-o menor e mais simples, porque tornou-se complexo ser escrito por alguém que era novo no idioma / novo no problema / não sabia ao certo o que estava fazendo.
Izkata
-5

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.
Vibhu Tiwari
fonte
5
-1: Uau! Eu acho que você precisa reduzir o LOC na sua resposta! Dói meus olhos lê-lo!
Jim G.
1
@ JimG .: Eu concordo que a resposta fere meus olhos, mas acho que isso é melhor resolvido aumentando o LOC (por exemplo, usando uma linha separada para cada item numerado).
Brian
Foi culpa do autoformatter, inserindo uma única linha em branco antes da lista curar a situação
Balog Pal