É menos linhas de código sempre melhor? [fechadas]

86

Qual desses estilos de programação é melhor?

var result = methodOne(methodTwo(a, methodThree(b)), c, d);

ou

var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);
    
por Mike Bryant 05.07.2013 / 05:28
fonte

23 respostas

216

Nas palavras do leigo:

O importante não é o número de linhas, mas a legibilidade do código.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler)

Nos exemplos que você deu, o segundo é definitivamente mais fácil de ler.

O código fonte é para as pessoas lerem.

Além disso, valores intermediários facilitam a depuração do código.

Os códigos one-liners, por outro lado, são úteis para mostrar às outras pessoas que você é "smart" e que você não se importa.

    
por 16.07.2013 / 20:08
fonte
100

Depende e o seu exemplo não é útil para tomar a decisão.

Enquanto menos linhas de código não são sempre melhores (em algum momento isso leva a ofuscação), elas geralmente são, simplesmente porque há menos coisas para rastrear quando tentando entender o código.

No seu exemplo específico:

Se os nomes dos valores intermediários realmente transmitem um significado que não é óbvio pelos nomes dos métodos e parâmetros usados para calcular esses valores intermediários, eles ajudam a entender o código.

No entanto, se os nomes dos valores intermediários não adicionarem informações, eles tornarão o código mais difícil de entender, já que são um estado adicional a ser monitorado. Mesmo que sejam imutáveis, eles forçam você a considerar se são usados apenas uma vez ou em lugares diferentes.

    
por 12.10.2013 / 00:17
fonte
54
Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say '(x++ && false) || y += 2' instead of 'x++; y += 2' and the first variant is just so much more concise and clearer as you can tell because it contains no semi-colons honestly I almost threw up writing the second one I mean who wants to use a character whose name contains a word related to your butt that's just dumb and anyways semi-colons introduce lots of vulnerabilities like what if you typed 'while(true) ;' that would just keep running forever and so its clearly better to have no semi-colons to avoid problems like that overall I'd say programmer salaries should be inversely proportional to the number of newlines and semi-colons in their code because everyone knows as soon as you start using a metric like that it starts working even better than before you incentivized it
    
por 06.10.2013 / 15:17
fonte
34

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates)

É claro que menos linhas não são sempre melhores. Mas na minha experiência, poucas linhas são melhores do que mais linhas em termos de legibilidade e facilidade de manutenção. Há exceções, é claro, e seu exemplo pode ser uma exceção.

O peso é necessário para construir uma aeronave. Mas deve estar nos lugares certos.

    
por 12.10.2013 / 00:22
fonte
11

Na primeira versão, é difícil ver quais parâmetros são passados para qual método. Então a segunda versão é claramente melhor. Em outros casos, no entanto, pode não ser tão óbvio.

A principal diferença da segunda versão é que permite nomear os valores intermediários . Pode haver casos em que esse nome é crucial para entender o código.

Se, entretanto, os valores intermediários forem chamados de algo como varOne , você também poderá omití-los alinhando-os.

    
por 04.07.2013 / 14:17
fonte
11

Parece que você está usando JavaScript, o que muda os parâmetros um pouquinho.

A menos que você tenha um motivo para armazenar os var , seria melhor não iniciá-los. Mas, você deve tornar a versão de instrução única o mais legível possível, adicionando espaço em branco e um comentário.

//Do X, Y, Z....
var result = methodOne(
    methodTwo(
        a, 
        methodThree(b)
    ), 
    c, 
    d
);
    
por 04.07.2013 / 19:48
fonte
9

As linhas de código são sempre melhores?

O curto é simplesmente não . Quanto mais longo, não , porque depende .

  • Por quanto tempo o código deseja encurtar? Se o código não couber na tela, encurtá-lo muitas vezes torna-o mais legível
  • Quanto é feito em linha única? Se é um acesso através de 10 objetos, é certamente uma boa ideia dividi-lo em várias linhas
  • O que é melhor? Escrever uma versão padrão longa ou usar uma função de biblioteca ou um acréscimo de sintaxe simples? Quantas pessoas sabem que açúcar / função? Um ótimo exemplo são expressões regulares. Com o regex único, você pode conseguir tanto quanto com muitas linhas de código - mas, às vezes, leva horas para entender o regex único. No entanto, existem alguns regex que são amplamente usados e pesquisáveis no google.

Qual destes estilos de programação é melhor?

Bem, o segundo é muito melhor em um aspecto. Se você precisar depurar o que acontece, você tem as variáveis para inspecionar e mais possibilidades para colocar o ponto de interrupção.

Por outro lado, não gosto de usar muitas variáveis locais, porque preciso inventar os nomes para elas. Eu odeio esses nomes como resultado 1/2/3, porque depois de algum tempo eu não sei o que é para o quê. Mas eu não quero gastar muito tempo inventando os nomes ... O primeiro exemplo é (para mim) realmente mais legível por causa dos nomes das variáveis ruins no segundo exemplo.

Normalmente eu começo com o primeiro código e o converto em segundo primeiro quando preciso depurar.

No entanto, se as expressões forem mais complexas, prefiro manter resultados intermediários em variáveis locais - mas essas variáveis locais devem ter nomes explicativos . Só então o código é mais fácil de ler.

    
por 04.07.2013 / 23:33
fonte
8

Minha regra é colocar cada operação em sua própria linha. Isso é especialmente útil ao percorrer o código com o depurador. Eu também gosto de atribuir o resultado de uma operação a uma variável antes de passá-la para que eu possa quebrar e examinar seu conteúdo. então ao invés de

var result = methodOne(methodTwo(a, methodThree(b)), c, d);

eu iria

var result3 = methodThree(b);
var result2 = methodTwo(a, result3);
var result = methodOne(result2, c, d);

Se não me engano, os compiladores java e .net JIT compilariam os dois exemplos da mesma maneira.

alternativamente, eu escreveria um comentário muito detalhado antes da linha explicando o que estou fazendo.

    
por 04.07.2013 / 15:59
fonte
5

Suspeito que o que todos querem ouvir é "não".

O fato é que o seu exemplo não está claro o suficiente para dar uma resposta sólida.

resultThirdMethod é um nome horrível. Acho a primeira versão muito mais clara que a segunda.

No entanto, se você pudesse dar nomes a suas variáveis - nomes que fornecem mais informações do que simplesmente de onde os dados vieram - então poderia ser melhor. Tudo depende da situação real.

    
por 04.07.2013 / 21:43
fonte
4

Neste exemplo em particular, não acho a primeira versão mais difícil de ler, é como ler uma expressão aritmética simples como (a + f(b)) * c * d . A segunda versão não adiciona nenhuma informação que ajude a entendê-la (a menos que as variáveis tenham nomes significativos que ajudem a entender um processo complicado).

O que eu sinto um pouco problemático com a segunda versão é que ela introduz uma complexidade adicional ao analisar o código. Um programador que lê o código precisa pensar se resultThirdMethod ou resultSecondMethod é usado em algum outro lugar e só para calcular result . E se você escrever um método cheio de tais declarações, não há uma linha clara de cálculo, você tem que verificar constantemente o que é calculado a partir de onde e onde. Então, nesse caso, se você quiser a versão mais detalhada, sugiro encapsulá-la em uma função separada:

function methodCombined(a, b, c, d) 
    var resultThirdMethod = methodThree(b);
    var resultSecondMethod = methodTwo(a, resultThirdMethod);
    return methodOne(resultSecondMethod, c, d);
}
// ...
result = methodCombined(a, b, c, d);

ou pelo menos coloque-o em um bloco de código para que o escopo das variáveis seja imediatamente visível:

var result;
{
    var resultThirdMethod = methodThree(b);
    var resultSecondMethod = methodTwo(a, resultThirdMethod);
    result = methodOne(resultSecondMethod, c, d);
}
    
por 04.07.2013 / 21:30
fonte
4

Depende de quão familiar o leitor provavelmente estará com esses operadores e seu domínio de problemas. Mesmo que todos os métodos sejam funções aritméticas, isso pode ajudar a dividi-lo.

Quebrar uma fórmula maior em pequenos passos pode estragar a legibilidade:

(let* ((term1 (* b b))
       (term2 (* 4 a c))
       (discriminant (- term1 term2))
       (twoa (* 2 a))
       (top1 (+ b (sqrt discriminant)))
       (top2 (- b (sqrt discriminant)))
       (root1 (/ top1 twoa))
       (root2 (/ top2 twoa)))
  (list root1 root2))

versus

(let* ((root1 (/ (+ b (sqrt (- (* b b) (* 4 a c)))) 
                 (* 2 a))) 
       (root2 (/ (- b (sqrt (- (* b b) (* 4 a c))))
                 (* 2 a)))
  (list root1 root2))

Quebrar fórmulas em pequenos passos é o que um compilador faz quando gera código intermediário. (Fortran: FORmula TRANslator.)

Quebrar expressões para facilitar a leitura ajuda, mas não "Fortran it" (exagere).

    
por 04.07.2013 / 23:30
fonte
3

O melhor estilo é aquele que torna o código mais legível (para um humano, isto é, os computadores não se importam). Mas "legível" depende muito de quem faz a leitura , de modo que depende do contexto. Isso é o suficiente, no entanto, para responder à sua pergunta: "O que quer que seja sempre melhor"? Então não , depende do contexto.

A primeira pessoa que deve ler o código é o próprio desenvolvedor. Se você escrever código de modo que você mesmo possa ler e entender daqui a quatro semanas, você já terá feito um bom trabalho - um trabalho muito melhor do que a maioria dos desenvolvedores no indústria (infelizmente).

Pode-se acrescentar algumas generalidades, no entanto. O código de leitura implica o uso do olho e do cérebro. Os olhos humanos cansam mais rápido quando têm que se mover muito, especialmente quando têm que se mover verticalmente (o movimento lateral é menos um problema). Usando menos linhas de código, todas as outras coisas sendo iguais, permitirá que o leitor segure o código com menos movimento ocular vertical, o que é um pouco bom.

Por outro lado, a análise da sintaxe que vai no cérebro vai querer usar tantas "âncoras visuais" quanto possível, e sofrerá certas atividades, em particular contando parênteses. Espalhar o código em mais linhas, com recuo, ajuda o cérebro. É realmente um compromisso entre a fadiga ocular e a fadiga cerebral e, insisto, o ponto de equilíbrio certo não é o mesmo para todos.

Em última análise, é uma questão de bom gosto. As pessoas que escrevem código feio também são pessoas felizes comendo uma pizza ruim.

    
por 12.10.2013 / 00:35
fonte
0

Você deu um mau exemplo.

A solução que você dá para resolver um problema melhor tem um bom design para ser compreensível e bom o suficiente para manter o código curto.

Se você puder criar um código mais compreensível, tornando-o mais longo, é algo a fazer, mas há um limite.

Sempre penso que o código que possui um bom design AND é mantido curto, garante mais facilidade de compreensão quanto menor for o seu tamanho.

Você deve se concentrar em um bom design e, em seguida, encontrar maneiras de tornar o código curto o suficiente para que as pessoas que o lerem possam entendê-lo sem fazê-lo rolar e rolar.

Então, para resumir, não há uma resposta realmente boa para isso, o importante é o quão bem você divide seu código em funções e seções, e como você pode torná-lo curto e fácil de entender.

A citação do Bill Gates é boa, mas há também a citação que fala sobre um trecho de código perfeito, que é onde você não pode tirar nada.

    
por 04.07.2013 / 23:35
fonte
0

Essa é uma dessas questões que eu acho que você decide qual a maneira que funciona para cada caso separado. Decidir se um determinado resultado deve ser armazenado em uma variável intermediária faz parte de ser um programador, parte da nave. Você usa as habilidades adquiridas em conjunto com os padrões de codificação em seu local de trabalho.

Nos dois exemplos inventados abaixo, eu provavelmente iria com 1A e 2A, por causa da legibilidade (muito ruído e redundância em 1B, uso muito longo e indireto de um array anônimo em 2B). Mas você não pode realmente apresentar uma lista exaustiva de padrões onde você possa estipular um caminho sobre o outro - novas situações surgem o tempo todo à medida que a arte da programação progride.

1A:
startManufacture(loadProductName(), isProductOk(loadProductState()));

vs.

1B:
String productName = loadProductName();
ProductState state = loadProductState();
boolean productIsOk = isProductOk(state);
startManufacture(productName, productIsOk);


2A:
boolean antennaCount = storage.getCount(currentDealer, items[ANTENNA_INDEX]);
boolean chassisCount = storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING);
orderManufacture(RADIO, antennaCount, chassisCount);

vs.

2B:
orderManufacture(RADIO, storage.getCount(currentDealer, items[ANTENNA_INDEX]), storage.getCount(currentDealer, items[CHASSIS_INDEX], EXTERNAL_SHIPPING));
    
por 05.07.2013 / 14:49
fonte
0

Eu diria que ambos os exemplos são igualmente ruins , mas isso é apenas por causa do código de exemplo insuficiente. Para poder dizer se um dos dois é melhor, você precisa fornecer um exemplo real.

Não há absolutamente nenhuma correlação entre o número de linhas de código-fonte e a qualidade do código.

Assumindo que desconsideramos o fato óbvio de que o código precisa fazer o que é suposto fazer, o aspecto mais importante é que ele seja facilmente compreendido pelos leitores.

A maneira "clássica" de fazer isso é adicionar comentários de código que descrevam a funcionalidade do código. Na minha experiência pessoal, é ainda melhor usar identificadores descritivos para métodos, variáveis e constantes.

Se, por exemplo, você vir uma sequência de código-fonte como essa, você entenderá imediatamente o que deve fazer e poderá examinar os métodos e variáveis individuais para (espero) determinar com a mesma facilidade que eles devem fazer o que deveriam fazer:

if (a_new_game_is_starting && hand_not_dealt_yet()) {
  deal_new_hand_to(all_players_at_table);
}

No exemplo acima, não há necessidade de adicionar nenhum comentário. O que um comentário diria que não é facilmente entendido a partir do código real? Isso é algo pelo que lutar - não precisar para adicionar comentários ao código para descrever o que ele faz.

Isso não é algo difícil de fazer. Tudo o que é necessário é que você pense no que realmente está tentando realizar e nomeie seus identificadores de um ponto de vista funcional.

    
por 07.07.2013 / 00:45
fonte
0

Mais importante do que legibilidade é manutenção , porque a principal razão pela qual lemos o código é mantê-lo. Manter frequentemente significa fazer alterações no código devido a pequenas ou grandes alterações nos requisitos.

ASSIM, pense nas mudanças nos requisitos que podem existir e tente torná-los o mais fácil possível. Se você puder levar o mantenedor diretamente para o código relevante, e deixá-lo fazer as alterações com edição mínima, ele achará que você é um ótimo programador!

OTOH, se as pessoas estiverem lendo o código para verificar sua exatidão, certifique-se de que seu raciocínio seja claro a respeito de porque está correto. Se as pessoas duvidarem da exatidão do seu código, elas provavelmente o reescreverão, o que provavelmente o quebrará. Para evitar isso, verifique se o código explica a si mesmo.

Além disso, certifique-se de explicar suas decisões relacionadas ao desempenho, porque uma maneira de um bom código ser destruído é ser reescrito em uma tentativa equivocada de torná-lo mais rápido.

    
por 07.07.2013 / 03:52
fonte
0
return ($this->main->context != "ajax" || in_array($this->type, $this->definition->ajax)) ? eval('return method_exists($this,"Show'.ucfirst($this->type).'") ? $this->Show'.ucfirst($this->type).'('.(count($args) ? join(",",array_map(create_function('$a','return (is_numeric($a) || preg_match("/^array/",$a)) ? $a : "\"".$a."\"";'),$args)) : "").') : null;') : '';

Encontrei esse código em um projeto que herdei há algum tempo. Eu acho que isso demonstra bem porque é uma má ideia tentar usar o menor número de linhas possível. É completamente ilegível e impossível depurar.

    
por 07.07.2013 / 10:54
fonte
0

Soletrar as coisas pode ajudar não apenas na legibilidade, mas também na capacidade de escrita.

Isso pode parecer uma pergunta boba da entrevista, mas me pediram uma vez em uma entrevista para escrever uma função para girar uma imagem em 90 graus. A origem e o destino são fornecidos (você não precisa fazer nenhuma alocação de memória) e a largura e a altura da fonte. Sim, é um problema fácil. Eu sugiro que você faça isso antes de continuar e veja se você tem algum problema.

.

Você fez? Você testou isso? Desde que me perguntaram em uma entrevista eu usei a pergunta em entrevistas também e o que eu encontrei foi que muitos programadores se confundiam. Eles escreveriam código como este

 void Rotate90(const Pixel* src, Pixel* dst, int width, int height) 
 {
    for (int y = 0; y < height; ++y) 
    {
      for (int x = 0; x < width; ++x) 
      {
         dst[???] = src[???];

E é aí que eles ficariam presos. Eles gastariam às vezes até 20 minutos no quadro branco tentando descobrir o que acontece neles ??? área. Muitas vezes eles acham que têm a resposta e escrevem coisas como

         dst[x * width + (height - 1 - y)] = src[y * width + x];

recebendo o fato de que usar width com dst está errado. Ou, muitas vezes, eles teriam o x e o y misturados em um lado ou outro.

O problema é que x , y , width e height trocam de significado porque, ao girar 90 graus, o destino fica com largura e altura altas, o que torna a referência a essas variáveis confusas. Eu sempre desejei que um programador adicionasse mais algumas variáveis para ajudar a torná-lo mais claro, como este

 void Rotate90(const Pixel* src, Pixel* dst, int src_width, int src_height)
 {
   int dst_width = src_height;
   int dst_height = src_width;

   for (int src_y = 0; src_y < src_height; ++src_y) 
   {
     for (int src_x = 0; src_y < src_width; ++src_x) 
     {
       int dst_x = src_height - src_y - 1;
       int dst_y = src_x;
       dst[dst_y * dst_width + dst_x] = src[src_y * src_width + src_x];
     }
   }
 }

Pareceu-me quebrar as coisas em seus significados explícitos que tornaria muito mais fácil escrever o código e muito mais fácil evitar erros. Eu senti que se eu visse um programador fazendo isso eu pensaria neles como sábio e os classificaria mais alto.

Sim, existem algumas otimizações que você pode fazer. Essa não é a questão. Sim, a matemática dentro da última declaração também pode ser dividida em linhas separadas. Isso também seria bom. O ponto é que adicionar mais linhas facilitou a compreensão para a pessoa que está escrevendo o código, e não apenas para uma pessoa que o leu mais tarde. Nesse caso, porque o significado de x , y , width e height é diferente em relação a dst vs src , fazer variáveis separadas para cada torna o código muito mais claro para ler AND escreva .

Continuando ... Da mesma forma, é útil poder inspecionar os valores antes que uma função seja chamada, especialmente se for uma função de uma biblioteca ou o sistema no qual você não pode entrar. Se você escrever um código como este

ctx.lineTo(x + Math.cos(angle) * radius, y + Math.sin(angle) * radius);

vs isso

var circleX = x + Math.cos(angle) * radius;
var circleY = y + Math.sin(angle) * radius;
ctx.lineTo(circleX, circleY);

No segundo estilo, você pode parar o depurador na linha ctx.lineTo e inspecionar circleX e circleY . Você pode achar que eles são NaN , o que provavelmente faria você verificar se x , angle e radius são realmente os nomes corretos, algo que você não seria capaz de fazer no depurador. (modo "estrito" provavelmente pega isso). Também permite que você registre facilmente os valores

console.log("cx: " + circleX = ", cy: " + circleY);

Ainda outro exemplo,

class Person 
{
public:
   ...
   const String& name() const { return m_name; }
   int age() const { return m_age; }

private:
   string m_name;
   int m_age;
};

vs

class Person 
{
public:
   ...
   const String& name() const 
   { 
     return m_name; 
   }

   int age() const 
   { 
     return m_age; 
   }

private:
   string m_name;
   int m_age;
};

Eu sei que alguns de vocês vão gritar com este exemplo porque seu estilo pessoal quer que getters e setters sejam de 1 linha, mas me ouçam ... quando depurar, dependendo do depurador, no primeiro estilo se você colocar um ponto de interrupção age or name o depurador não poderá inspecionar this nem m_age nem m_name , portanto você não terá como verificar antes que a função retorne o que ela retornará ou a que objeto está fazendo referência. No segundo estilo você pode colocar pontos de interrupção nas linhas return e você poderá inspecionar tudo.

O ponto desta resposta é que mais linhas geralmente não são boas apenas para a legibilidade. Também costuma ser bom para gravabilidade e depuração.

    
por 13.10.2013 / 12:37
fonte
-1

Não.

Na verdade, eu iria mais longe e diria que menos linhas de código raramente são melhores.

Agora, isso não quer dizer que não encapsule as chamadas de método, mas no seu exemplo acima, ao depurar - será muito difícil ver o resultado do methodThree e methodTwo quando tudo estiver assim.

Muitos códigos em um método fazendo muitas coisas são ruins. Vários métodos pequenos que são chamados e atribuídos a variáveis locais aumentam a legibilidade, aumentam a capacidade de manutenção e não têm custo real, já que o compilador otimiza a otimização.

    
por 04.07.2013 / 13:29
fonte
-1

Pense no básico. Por que escrevemos código, quando queremos adicionar alguma funcionalidade e entregá-lo a outro desenvolvedor, ele pode entender seu código ou não, por que é importante estruturá-lo, por que alguém deve seguir as diretrizes padrão básicas?

As respostas são as seguintes:

Por que colocamos comentários em nosso código.
Para os desenvolvedores (que podem aproveitar essa pequena documentação para entender o código e a funcionalidade de rotina), os computadores ou os sistemas de codificação / decodificação simplesmente ignoram os comentários e lidam apenas com o código real. Por exemplo: pacote de desenvolvimento e versão de manifesto,

Se usarmos a segunda opção, é fácil de ler e ampliar, e não é necessária muita orientação de um novo desenvolvedor que estenda nosso código. Mas se usarmos a primeira opção, que é menos documentada apenas a pessoa que escreveu este código ou pode entender o seu propósito, e não a equipe inteira. Estamos trabalhando em um ciclo de desenvolvimento rápido, no qual precisamos trabalhar em projetos diferentes e não temos muito tempo para nos coordenarmos com outros departamentos, portanto, neste caso, a segunda abordagem funciona bem e outro desenvolvedor pode facilmente estender a funcionalidade. É tudo uma questão de dependência: trabalhamos na modularização de código onde milhares de desenvolvedores trabalham em milhares de funções e eles sabem apenas o que retornar, o que passar para a função e qual variável é atribuída a qual, e para que.

Para usuários únicos ou pequenos programas, a primeira abordagem é ok quando a equipe está trabalhando em conjunto, mas quando as pessoas estão trabalhando remotamente o que fazer, esse é o ponto que você provavelmente seguirá com a segunda opção, otimização é outra técnica para encurtar o código, mas só depois feliz com a saída.


computador é máquina, só entendo zero e a própria linguagem, mas se escrevermos código que orienta outro desenvolvedor sobre o programa como segunda abordagem, novas pessoas também podem usar isso como orientação ou editar o programa,
computador entender 0 e 1 e humano pode entender os comentários
então eu gosto de segunda abordagem que ajuda desenvolvedor para entender o que está acontecendo dentro de loop ou função
eg: ** suponha que se você está trabalhando em algum projeto e você usa 1ª via e em alguns casos você teve outra tarefa e outro desenvolvedor está trabalhando em seu código, ele entende isto ou não? Não é questão de simplicidade ou como documentar, é tudo sobre ** como farward nosso código para o nosso parceiro quando ele deseja atualizar o código com suporte livre de problemas.
segunda abordagem é boa para parceiros e desenvolvedores e 1ª opção funciona bem quando estamos trabalhando em plataforma web, ou roteiro de escrita onde o tamanho do código é importante

TL; DR:
Documente seu código . Escreva comentários quando estiver escrevendo. Isso economizará um tempo valioso de três meses quando você voltar e não conseguir entender o que o código está fazendo. Além disso, seus colegas de trabalho cantarão elogios de você quando puderem realmente entender o que você está fazendo, e podem facilmente estender / refatorar ou modificar o código escrito por você. Não exagere , no entanto.

Se menos linhas de código fizerem sentido, vá em frente e faça isso em várias linhas. Mas não faça fazer com que digitar menos linhas faria com que você tivesse que adicionar comentários para explicar seu código. Deve ser tão auto-explicativo quanto possível.

    
por 04.07.2013 / 20:57
fonte
-1

E sobre

var result = methodOne(   methodTwo(    a, 
                                        methodThree(b)
                                   ),
                          c,
                          d
                      );

Isso provavelmente será ainda mais aprimorado com a ajuda de um IDE de decendência, imprimindo linhas que correspondam às chaves.

    
por 05.07.2013 / 08:14
fonte
-1

Em suma, o cérebro humano, para a maioria das pessoas comuns , pode comportar 7 coisas diferentes na melhor das hipóteses. Isso é para pessoas comuns, e isso é uma média. (Eu tenho medo de não ter encontrado a fonte da minha declaração)

Como conseqüência, se você quiser escrever código que qualquer um possa ler, ele não deve usar mais de 7 variáveis / conceitos / funções / operações diferentes.

por exemplo:

rotate(translate(rotate(translate(circle,50,0),0,10,pi),-50,0),0,10,pi)

lá é realmente difícil entender o que está acontecendo, espantosamente essas linhas não fazem absolutamente nada no sentido geométrico:

circle = translate(circle,50,0)
circle = rotate(circle,0,10,pi)
circle = translate(circle,-50,0)
circle = rotate(circle,0,10,-pi)

também é por isso que é mais fácil ler funções com menos de 40 linhas de código.

    
por 06.07.2013 / 11:09
fonte
-2

Ambos os exemplos são realmente ruins.

O que acontece se o methodOne falhar? O que acontece se o método Two falhar? O que acontece se o methodThree falhar? Você obviamente omitiu a verificação de erros por clareza aqui, mas é um ponto importante - adicionar verificação de erros adicionará mais linhas de código (o que por si só deve responder à sua pergunta) para linhas extras de código significativo na verdade, faz algo nunca deve ser visto como algo ruim.

Além disso, eu ainda preferiria o segundo exemplo. A razão é porque é mais sustentável; você pode inserir mais facilmente uma chamada para methodTwoPointFive entre as chamadas para methodTwo e methodThree, por exemplo, caso os requisitos futuros precisem.

    
por 04.07.2013 / 18:37
fonte