Quão rigoroso você deve ser quanto à indentação / espaço em branco? [fechadas]

8

Nosso processo de desenvolvimento é o seguinte

codifique a tarefa -> código e documentação de QAs de outra pessoa -> tarefa é mesclada no tronco.

Recentemente, um colega se recusa a passar o controle de qualidade do código devido a problemas com recuo e espaço em branco.

Aqui estão exemplos desses problemas (a sintaxe é SAS):

Espaço em branco adicional:

        %if &syserr gt 0 %then %goto err; /*last line of code*/




/* Footer area*/

Linha extra de espaço em branco, e não recuado dentro de proc class:

 /* End Of header * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */


    proc sort data = %dataset ;
    by id; 
    run;
    %if &syserr gt 0 %then %goto err; 

    proc sort data = &second_dataset.;
    by id;
    run; 
    %if &syserr gt 0 %then %goto err; 

Espaço em branco extra entre as etapas:

        /*join all details on for each record*/
        proc sort data = &data out = data_srt ; 
              by &conditions; 
        run;
        %if &syserr gt 0 %then %goto err;

        proc sort data = &data2.;
              by &conditions.;
        run; 
        %if &syserr gt 0 %then %goto err; 




        /*cartesian join*/
        data new_data;
              join data 
                          &data2.  ;
              by &conditions; 

        run;

A questão é que, sendo um bom programador, analisar seu código e corrigir esse tipo de coisa é a coisa certa a fazer, ou isso é ridículo?

Há uma complicação adicional: como não temos integração contínua ou teste automatizado, o QAer não pode corrigir rapidamente esses problemas e confirmar o código, pois corre o risco de excluir acidentalmente ponto-e-vírgula ou algo assim. (Para ser justo, o risco se aplica ao desenvolvedor inicial que faz essas alterações; portanto, se esse erro ocorrer, ele precisará ser corrigido e seguir em frente).

Dwjohnston
fonte
1
Eu não sei SAS, mas espaço em branco extra é bastante anal. A indentação me parece um ponto justo.
precisa
@ErikReppen Por outro lado, esses exemplos têm 4 linhas em branco entre os segmentos de código. Esse é um tipo de excesso ...
Izkata

Respostas:

16

Sim, essa é a resposta certa. O estilo de indentação deve ser consistente para todo o código.

Uma grande parte do valor da indentação consistente é que ela é consistente. Dessa forma, as pessoas aprendem a lê-lo facilmente, o que acelera a todos.

Minha regra geral é que qualquer estilo de indentação que a equipe deseje seja bom, desde que possa ser aplicado mecanicamente. Aplicá-lo mecanicamente significa que você não precisa aprender os detalhes do padrão ou gastar tempo mexendo em espaço em branco.

A formatação mecânica também se torna outra maneira de destacar os erros. Se você acha que incluiu o código em um bloco, a ferramenta de formatação o recuará e será óbvio que você errou. Isso também facilita a refatoração - no nível trivial, quando você extrai um bloco de código para uma função, a formatação automática remove a indentação extra.

A formatação automática também significa que, se você realmente não consegue viver com o padrão que todo mundo usa, pode formatar o código da maneira que desejar e reformatá-lo novamente antes de fazer o check-in. Como você tem uma etapa de revisão, obviamente faça isso antes da revisão e, se não o fizesse, seria retirado.

O recuo do GNU é uma ferramenta que pode ser criada para formatar automaticamente quase tudo. Fiz uma pesquisa rápida e parece haver ferramentas para formatar automaticamente o código SAS, mas as ferramentas SAS não fazem isso por você.

Móż
fonte
6
+1 para usar a ferramenta. É meio ridículo corrigi-lo manualmente quando você pode simplesmente executar uma ferramenta no gancho de confirmação.
imel96
1
@ imel96 Às vezes, existe um espaço em branco intencional para facilitar a legibilidade, que uma ferramenta automática estraga. Portanto, deve ser opcional, algo que você pode acionar quando quiser, não forçado com cada confirmação.
Izkata
@ Izkata: Eu ainda estou vendo uma ferramenta de formatação que não possui um código "não formate este bit" que você pode usar. Mas também passei muito tempo desde a última vez em que desejei desativar a formatação automática. Eu admito ocasionalmente usar construções de código um pouco estranhas para obter o formato desejado (condicionais de várias linhas com "se verdadeiro e" na primeira linha, por exemplo). Mas a condicional multilinha é um cheiro de código por si só, portanto, adicionar um pouco para torná-lo menos ilegível é suficiente para a IMO.
Moz
@ Izkata, o problema de tornar a ferramenta opcional é que, assim que uma pessoa opta por um arquivo, ninguém mais pode executar a ferramenta nesse arquivo novamente ou eles quebram o código "não formate este arquivo". O que significa que eles devem mover o arquivo para você e dizer "corrigir a formatação". Toda vez que é modificado. Portanto, não, opcional não funciona. Você precisa usar os códigos sem formato nos blocos especiais de código / comentário.
Moz
@ Ᶎσᶎ Então você corrige o recuo que é realmente ruim. Não o execute cegamente por todo o arquivo. O vim , por exemplo, permite selecionar um pedaço do arquivo e reindentá-lo automaticamente, ignorando o restante do arquivo.
Izkata
5

Esta é absolutamente a coisa correta a se fazer. Uma das maiores partes da qualidade do código é sua legibilidade. Se você não recuou seu código corretamente e possui espaços em branco aleatórios em todos os lugares, isso reduz a legibilidade do código.

Geralmente, sua equipe de desenvolvimento deve seguir os mesmos padrões de qualidade de código quando se trata de recuo e espaço em branco. Se outros módulos em sua base de código não colocarem espaço em branco extra entre as etapas, este também não deverá (a menos, é claro, melhora a legibilidade).

Eu não sou um programador SAS, mas se estou revisando o código e o recuo está fora de sintonia e não parece arrumado, certamente comento sobre o acompanhamento e, se realmente ruim, falha na revisão.

Deco
fonte
3

Como o tio Bob diz em seu livro , a formatação (até o espaço em branco) é incrivelmente importante. O software tende a ser lido com muito mais frequência do que o escrito, portanto cabe a nós torná-lo limpo e fácil de ler. É um método de comunicação.

Idealmente, ao trabalhar em equipe, você determina um padrão e todo mundo o segue. Idealmente, em vez de especificar o padrão nas revisões de código individuais, configure uma ferramenta que fará o trabalho por você. (Não tenho certeza de qual ferramenta funcionaria para o seu caso; algo como checkstyle para Java ou StyleCop para C #).

Então, eu conversava com seu colega e veria se você não consegue apresentar algumas diretrizes sobre espaço em branco. Dedicar alguns minutos para limpar seu código vale a pena se tornar as coisas consistentes na linha.

Allan
fonte
2

Depois de uma experiência há muitos anos, lendo um código F-16C / D em que o recuo foi quebrado, devo dizer que obter a indentação correta é extremamente importante.

É tão criticamente importante que não deve ser feito à mão e não deve ser reparado à mão. É para isso que servem os computadores.

Eles criam programas de computador que podem reformatar automaticamente o código-fonte para corresponder ao estilo preferido da sua empresa. Conecte um deles ao seu sistema de controle de código-fonte, para que o código seja automaticamente colocado em conformidade sempre que for feito o check-in.

John R. Strohm
fonte