Devo escrever código compacto ou código com muitos espaços? [duplicado]

15

Eu tenho dois amigos que têm escolas de pensamento completamente diferentes sobre como definir seu código.

O primeiro diz que o código deve ser bem recuado e usar muitos espaços e nomear variáveis de maneira criteriosa para organizar as coisas de forma que você possa entender imediatamente a hierarquia e semântica do código. código.

Veja uma amostra de como é o código dele:

var Stack = function () {

    var pair = function ( first ) {
        return function ( second ) {
            return function ( dispatcher ) {
                return dispatcher ( first ) ( second );
            };
        };
    };

    var getFirst = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return x;
            };
        } );
    };

    var getSecond = function ( pair ) {
        return pair ( function ( x ) {
            return function ( y ) {
                return y;
            };
        } );
    };

    var emptyStack = function () {
        return function () {
            return null;
        }
    };

    var stack = emptyStack ();

    var self = {
        push: function ( item ) {
            stack = pair ( item ) ( stack ); 
            return self;
        },
        pop: function () {
            var top = getFirst ( stack );
            stack = getSecond ( stack ) || emptyStack ();
            return top;
        },
        top: function () {
            return getFirst ( stack );
        }
    };

    return self;
};

O segundo diz que é melhor escrever seu código de maneira mais compacta para que você possa ver uma parte maior da imagem de uma só vez e ser capaz de reconhecer mais imediatamente como uma parte o programa afetará outro.

Aqui está o mesmo programa escrito em seu estilo:

var Stack=function(){
var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
var fst=function(p){return p(function(x){return function(y){return x}})};
var snd=function(p){return p(function(x){return function(y){return y}})};
var empt=function(){return function(){return null}};var stk=empt();
var slf={push:function(val){stk=pair(val)(stk);return slf},
pop:function(){var top=fst(stk);stk=snd(stk)||empt();return top},
top:function(){return fst(stk)}};return slf}

Eu pessoalmente prefiro escrever código da primeira maneira, mas eu realmente não tentei o segundo caminho, então talvez eu não esteja acostumado com isso.

Tenho notado que, quando olho para o código Javascript da maioria dos sites profissionais, eles geralmente usam o segundo estilo, então pode haver alguma coisa nele.

Além de apenas preferências estilísticas subjetivas, existe uma razão para preferir uma em detrimento da outra?

    
por Peter Olson 23.05.2013 / 16:55
fonte

7 respostas

17

Você deve usar a primeira abordagem porque ela é dimensionada para programas maiores.

A mentalidade de "preciso ver como tudo afeta tudo" é prejudicial ao desenvolvimento de software. Você quer funções / objetos desacoplados, para que você possa mudar uma coisa sem quebrar outra função distante / não relacionada.

Mesmo se você usar um estilo de codificação compacto, você terá mais código do que pode caber na tela de uma só vez.

Uma solução melhor (de Clean Code de Robert Martin) é listar as funções públicas de "alto nível" primeiro, e fazer com que cada função permaneça em um nível de detalhe.

    
por 23.05.2013 / 18:14
fonte
2

A maioria dos IDE-s permitirá recolher a primeira amostra em 8 (ou mesmo 1) linhas pequenas, para que você possa ver a grande figura. A segunda amostra, pelo contrário, não pode ser facilmente igual à primeira.

O primeiro exemplo é mais fácil de entender, especialmente para iniciantes. Revela a hierarquia e a seqüência das ações realizadas. Além disso, os novatos da OMI prefeririam ter dificuldades em compreender a segunda amostra de uma só vez, porque ela parece bastante "assustadora" e complicada.

Então, se você trabalha em um ambiente de profissionais mais ou menos experientes, eu prefiro a segunda amostra - se você está acostumado a esse estilo, você pode entender a idéia toda de relance. Mas como na realidade poucos (ou nenhum) ambiente de desenvolvimento consistem apenas de desenvolvedores experientes, a primeira amostra é melhor.

P.S. Se você não gosta de escrever todos esses espaços e novas linhas manualmente, você pode ter uma ferramenta automatizada para isso.

    
por 23.05.2013 / 17:22
fonte
2

Eu geralmente escrevo código recuado, semelhante ao # 1, mas com menos linhas em branco. Recuos permitem os problemas de detecção com colchetes facilmente. Isso, combinado com cada tarefa em sua própria linha, mantém as coisas mais fáceis de ler. O preenchimento de tabulação permite o uso de nomes de variáveis mais longos sem digitar muito mais.

Sim, é mais longo, mas não há nada de errado em escrever um código longo. Assim como estou usando parágrafos nesta resposta para facilitar a leitura, por que não fazer o mesmo em seu código? Como o intérprete não sabe a diferença *, a única pessoa que se beneficia é você.

O Emacs tem um plug-in VHDL que eu uso diariamente que embeleza automaticamente o código através de um atalho de teclado. Isso permite mais foco na codificação, em vez de gastar tempo na formatação.

* dependente do idioma. Algumas linguagens, como python, usam recuos como parte da sintaxe, caso em que o intérprete sabe a diferença.

    
por 23.05.2013 / 17:49
fonte
1

Concordo com o que o superM disse. Meus dois centavos:

Eu prefiro o primeiro (não nesse extremo) porque dessa forma eu posso manter o código muito mais facilmente. Mesmo que eu tenha que mudar meu próprio código de 6 meses atrás, não vou entender o segundo estilo tão rápido quanto o primeiro.

O que você vê em JavaScript provavelmente foi escrito de forma mais humana, e até mesmo com comentários, mas algum semilaborador fez algumas alterações mecânicas (como reduzir o nome de uma variável de usersFacebookID para a e excluir todos comentários). Isso reduz a quantidade de dados enviados para um usuário, e esse é o principal gargalo dos aplicativos da Web, por isso o site parece carregar mais rápido. (E o usuário final não se importa com o estilo dos códigos).

    
por 23.05.2013 / 17:57
fonte
1

Se o seu IDE não oferecer suporte à análise e à dobra do seu idioma, talvez seja necessário um formulário mais conciso, mas, no geral, será mais difícil detectar erros. A densidade de informação é tão alta que você poderia facilmente superar algum erro. Além disso, o comprimento das linhas se tornaria bastante longo nos casos em que você precisa fazer várias chamadas em uma função, o que exigiria a rolagem para o lado. (muito mais irritante, em seguida, rolando para baixo, que é o que a maioria dos nossos IDEs são projetados para fazer) Se você estiver usando a linguagem de script s que será interpretada em vez de compilada, use uma minidificador antes de enviá-la. O uso de um minidificador é uma prática comum em empresas de desenvolvimento da Web ao usar JS por motivos de largura de banda. Em linguagens interpretadas, o espaço em branco é ruído. Os compiladores geralmente removem qualquer espaço em branco excessivo quando eles tokenizam o código-fonte, deixando apenas informações úteis após o processamento. (para byte código ou linguagem de máquina) Compiladores só tem que lidar com o ruído uma vez. Os intérpretes têm que lidar com o barulho toda vez. (embora a maioria tenha algum tipo de cache para aliviar o problema nos dias de hoje.)

No final, depende da plataforma usada para editar sua origem e o idioma / ambiente no qual você pretende usar seu código, mas eu votaria na opção 1.

    
por 23.05.2013 / 18:15
fonte
1

Concordo com o amigo 1

Do ponto de vista do compilador, não importa ... e a opção 2 irá economizar apenas alguns bytes de tamanho de arquivo no seu disco rígido gigaByte

De uma perspectiva humana, não importa para você como você usa hoje, como você sabe o que escreveu.

Mas quando você voltar a ela em um dia, semana, mês ou ano - ou outra pessoa voltar a ela, a Opção 2 será muito menos legível e muito menos compreensível.

    
por 23.05.2013 / 20:34
fonte
0

Não faça extremos! Eu preferiria escrever

var Stack=function(){
    var pair=function(x){return function(y){return function(f){return f(x)(y)}}};
    var fst=function(p){return p(function(x){return function(y){return x}})};
    var snd=function(p){return p(function(x){return function(y){return y}})};
    var empt=function(){return function(){return null}};
    var stk=empt();
    var r={
        push:function(val){stk=pair(val)(stk); return r},
        pop:function(){var top=fst(stk); stk=snd(stk)||empt(); return top},
        top:function(){return fst(stk)}
        };
    return r}

É compacto e legível.

    
por 23.05.2013 / 17:53
fonte