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

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

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

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.

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.

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.