Devemos incentivar estilos de codificação em favor da autonomia do desenvolvedor ou desencorajá-lo em favor da consistência?

14

Um desenvolvedor escreve if/else blocos com instruções de código de uma linha como:

if (condition)
   // Do this one-line code
else
   // Do this one-line code

Outro usa chaves para todos eles:

if (condition) 
{
   // Do this one-line code
}
else
{
   // Do this one-line code
}

Um desenvolvedor primeiro instancia um objeto e o usa:

HelperClass helper = new HelperClass();
helper.DoSomething();

Outro desenvolvedor instancia e usa o objeto em uma linha:

new HelperClass().DoSomething();

Um desenvolvedor é mais fácil com arrays e for loops:

string[] ordinals = new string[] {'First', 'Second', 'Third'};
for (i = 0; i < ordinals.Length; i++)
{
    // Do something
}

Outra escreve:

List<string> ordinals = new List<string>() {'First', 'Second', 'Third'};
foreach (string ordinal in ordinals)
{
    // Do something
}

Tenho certeza de que você sabe do que estou falando. Eu chamo de estilo de codificação (porque eu não sei como é chamado). Mas o que quer que chamemos, é bom ou ruim? Incentivar isso tem um efeito de maior produtividade dos desenvolvedores? Devemos pedir aos desenvolvedores que tentem escrever o código da maneira como lhes dizemos, para que todo o sistema se torne consistente com o estilo?

    
por Saeed Neamati 13.09.2011 / 20:37
fonte

14 respostas

19

Um documento de padrões de codificação é útil. É mais útil quando é curto o suficiente para que qualquer um possa lembrar de tudo sem muita dificuldade e quando não causa ninguém muita dor.

Como você escolhe recuar código em sua organização, ou capitalizar nomes, ou implementar seus loops, ou comentar seu código, não importa muito; a parte útil é fazer todo mundo escrever um código que pareça o mesmo de todo mundo.

  • Evita ter que gastar um minuto para recalibrar sua expectativa de onde os suspensórios devem estar e cada vez que você olha para o código de outra pessoa.
  • Evita ter vários estilos diferentes de código no mesmo arquivo.
  • Talvez o mais importante, ter um padrão escrito evita discussões sobre práticas de codificação durante revisões de código.

Mais uma vez, o que os padrões são não importa tanto quanto ter algum tipo de padrão simples e direto. Então, coloque todos os seus desenvolvedores em uma sala e deixe-os discutir quais devem ser os padrões. Essa reunião pode continuar indefinidamente, então as regras são:

  • Qualquer coisa não decidida até o final da reunião será decidida pelo gerente.
  • A reunião terminará depois de duas horas, ou quando alguém começar a gritar ou chorar, o que ocorrer primeiro.
  • O padrão inteiro caberá (em tamanho de tipo razoável!) em uma folha ou dois de papel, frente e verso somente se for absolutamente necessário.

Considere a adoção de alguém | else | padrões como ponto de partida para sua própria reunião de padrões de codificação , ou como forma de evitar completamente a reunião.

Uma vez acordados, os desenvolvedores devem poder (e devem esperar) policiar-se. O desvio ocasional do padrão não deve ser um grande problema (e pode até ser justificável), mas a recusa irremediável de abandonar algum estilo pessoal favorito em favor do padrão deve resultar em realocação imediata para o escritório com os canos de água com vazamento, ou o que for .

Demian Brecht aponta para ferramentas de lint. Estes são um complemento perfeito para um documento de padrões de codificação. É bom simplesmente seguir os padrões de estilo ; É importante manter os padrões de codificação relacionados a práticas perigosas. Ninguém além do autor verificará se cada linha de código atende ao padrão de estilo, mas você certamente deve considerar a criação de uma ferramenta de lint no fluxo de trabalho de sua equipe para detectar automaticamente possíveis bugs. Além disso, a própria ferramenta pode codificar as práticas aceitas para que você não precise listá-las individualmente nos padrões de codificação; basta especificar a configuração da ferramenta.

Nota: A ideia de "padrões de codificação" não é exclusiva da programação. "Padrões de codificação" são usados em muitos campos, às vezes dentro de uma organização, com mais frequência em toda uma indústria ou profissão. Alguns exemplos:

Em cada caso (e muitos outros), um profissional competente poderia facilmente entender o "código" que não atende ao padrão esperado. Por que tantas indústrias persistem em escrever requisitos detalhados para documentos que nem precisam ser analisados por um compilador? Porque o estilo é importante . Apresentar informações em um estilo padrão permite que o leitor se concentre inteiramente no conteúdo, torne a leitura mais rápida e facilite a compreensão e reduza os erros.

    
por 13.09.2011 / 23:07
fonte
16

O estilo não importa.

Lá, eu disse isso.

Após 30 anos e centenas de sites de clientes, e código de (estimando) 500 (ou mais) membros da equipe ao longo desses anos, descobri que o estilo não importa.

Comece a trabalhar primeiro.

Faça com que ele use um volume ideal de recursos (ou seja, estrutura de dados correta, algoritmo correto).

Fuss over "style" depois de tudo else ter sido resolvido. Fuss de "estilo" apenas com ferramentas, nunca manualmente.

    
por 13.09.2011 / 21:08
fonte
4

Existem estilos de codificação e há cheiros de codificação. Não foi uma vez que eu encontrei:

    if(debugCondition)
//         printf("DEBUG: state:%s at debugCondition\n",dbg_state());

    for(i=0; i<MAX;i++)
    {
       //some essential business logic
    }

Meu empregador anterior foi rigorosamente proibido usando multilinha if() sem chaves. Foi considerado uma falha do tipo "faça novamente e você está demitido". Os constructos permitidos foram

     if(condition) break; 
     if(condition) continue; 
     if(condition) return; 
     if(condition) for()...; 

Isso resultou de um erro como o que mostrei acima, que levou algumas horas para parar a página principal do portal.

Existem coisas que você deve sempre fazer. Como switch() :

     case 1:
         something();
     break;
     case 2:
         something();
     return;
     case 3:
         something();
     continue;
     case 4:
     case 5:
         something();
     break;
     case 6:
         something();
     //fallthrough;
     case 7:
     ...

Enquanto isso, digite:

     case 1:
         something();
     case 2:
         something();
     break;

sem fechar um case com //fallthrough é considerado um bug.

Geralmente, existe o padrão de codificação, que é a diretriz que pode ser ignorada, interpretada de forma criativa ou modificada para determinadas necessidades. E há a seção sobre "cheiros" e deve ser obedecida rigorosamente.

    
por 14.09.2011 / 12:03
fonte
3

Crie consistência com um bom design inicial. O que você descreve na pergunta é nada menos que microgerenciamento. Eu faço muito desenvolvimento web. Então eu sou a favor do desenvolvimento RESTful e CRUD expostos como serviços. Isso garante entidades simples e bem definidas que podem ser usadas de várias maneiras.

Esse design também permite delegar detalhes de implementação a outros desenvolvedores. Dessa forma, eles estão preenchendo os espaços em branco em vez de criar um design de sistema completo.

A falta de um design geral cria inconsistências no sistema. Crítica de iterações básicas e construções de looping faz pouco para melhorar o design do sistema. Esses tipos de problemas são melhor resolvidos com uma abordagem de mãos livres, StyleCop.

Você pode desenhar um diagrama relativamente simples do design geral do seu sistema? Um design que descreve os elementos / entidades envolvidos em um para um novo desenvolvedor de equipe. Se você não pode, ou está altamente envolvido, então o design está faltando.

    
por 13.09.2011 / 20:53
fonte
3

IMHO depende ...

Seus dois primeiros exemplos não são apenas uma questão de gosto pessoal para mim.

if (condition)
   // Do this one-line code
else
   // Do this one-line code

(sem parênteses) = mais propenso a erros, se mais código for adicionado mais tarde:

if (condition)
   // Do this one-line code
else
   // Do this one-line code
   // ...and this line as well... oops! this will actually execute either way

E isso é menos conveniente para depurar:

new HelperClass().DoSomething(GetSomeData()); // etc.

Você não pode simplesmente definir um ponto de interrupção onde você precisa. Se isso é um caso único - bastante justo, mas nós o discutimos como uma questão de estilo, e uma vez que você tenha coisas assim em todo lugar, a depuração fica mais desagradável do que tem sido.

Quanto ao seu terceiro exemplo (para vs foreach), eu vejo como uma questão de gosto.

    
por 14.09.2011 / 00:07
fonte
2

Nem Eu evitaria regras rígidas de codificação para evitar ser entediante, excêntrico, microgerenciamento e, pior do que tudo, perder tempo. Seu senso de autonomia é o seu próprio problema. Se eu quiser que você se sinta melhor consigo mesmo, vou comprar uma rodada da sua bebida favorita. Além disso, faça algo.

    
por 13.09.2011 / 21:52
fonte
2

Uso de convenções, nomes de variáveis, nomes de classes etc. é uma boa prática. Mas os estilos de codificação, como os exemplos que você fornece, são bastante triviais e não afetam a legibilidade nem a eficiência do código. Por outro lado, a sobrecarga de impor um determinado estilo combinado com o esforço dos desenvolvedores em segui-lo causará problemas.

    
por 13.09.2011 / 22:55
fonte
2

Use uma ferramenta de linting padrão do setor (aparentemente FxCop para C #). Embora não seja o fim, a consistência é importante em grandes projetos que têm várias pessoas trabalhando neles.

Se você está apenas trabalhando em seu próprio projeto ou pequena equipe, muitos argumentam que é um exagero. Eu acredito de outra forma (eu uso PEP8 para Python, mesmo em meus projetos pessoais de desenvolvedor único). / p>

A maioria dos exemplos que você deu, no entanto, provavelmente não seria detectada por uma ferramenta de linting, pois eles simplesmente não importam.

    
por 13.09.2011 / 23:05
fonte
1

Em última análise, é o programador que conduz a programação. Existem problemas de estilo, mas eles são secundários para obter o programa.

É útil dar aos programadores alguma orientação de estilo. Isso pode / deve ser feito antes que os programadores sejam colocados em funcionamento, especialmente se forem relativamente iniciantes no ambiente ou se programarem. Dada a orientação, alguns programadores terão muito estilo, outros menos. A orientação dada no início do projeto ajudará o primeiro grupo de programadores, facilitando assim a tarefa geral. Pode fazer pouco para o segundo grupo, que irá (esperançosamente) inventar em criatividade, o que lhes falta em conformidade.

    
por 14.09.2011 / 01:43
fonte
1

Acho que se resume ao tamanho do projeto e quantas pessoas estão trabalhando nele. Um programador habilidoso pode olhar para ambos os estilos de formato diferentes e saber o que estava acontecendo em ambos, mas é preciso haver uma confirmação para que o olho possa capturá-lo facilmente. Se você vai fazer a sua única linha com as chaves curle, então esse projeto não deve usá-las. Quem está liderando esse projeto deve ter essa escolha. Eu gosto de coisas que parecem claras e também muito compactas como eu posso consegui-las. Se você vai fazer uma linha única se os estatutos parecerem melhor com isso

if() {}
else() {}

Ou até mesmo:

if() {} else () {}

Mas uma única linha se não deve usar o espaçamento de uma mulitilina se. É assim que faço as coisas. Eu não me importo com o modo como o objeto é chamado e isso depende de quantas vezes ele é chamado. Se ele for chamado algumas vezes, eu prefiro iniciar o objeto e depende se ele tiver constuctors e o que não também. Porque se você tem um construtor e você liga:

Object.method();
Object.method2();

Então você acabou de chamar o método do objeto constuctor duas vezes, quando poderia ter sido evitado, instanciando o objeto completamente.

Quando se trata de foreach e for loops É também sobre o lanauge que alguns lanauges lhe dão melhor controle ao olhar para o array em um loop foreach, então você tem a chave e o valor em arrays temporários. E eu sei que alguns lanagues têm algum tipo de otimização porque eles podem olhar para o loop e saber exatamente quantas vezes ele será chamado.

    
por 14.09.2011 / 03:28
fonte
1

Embora o seu primeiro exemplo não seja ótimo (o argumento de que é mais propenso a erros sob modificação tem algum peso), em geral eu cresci para preferir que os desenvolvedores usem estilos de codificação ligeiramente diferentes.

Depois de trabalhar com o código de outros membros da equipe, às vezes por apenas alguns meses, ele essencialmente começa a trabalhar em linha e em linha git blame . Depois de ter estado na minha empresa por mais de 10 anos, provavelmente posso dizer com 80% + precisão que escreveu qualquer classe em qualquer lugar em nossas 500 mil linhas de código, apenas olhando para ela.

Embora exista um pouquinho de "tempo de rampa" quando você começa a olhar para um código que usa um estilo com o qual você não concorda, o que você realmente está fazendo nesse momento é dizer "ah, isso parece com John Doe código (porque ele usa o estilo X, mas não o estilo Y, etc) ". E isso traz consigo um monte de contexto. Para uma primeira aproximação, você sabe o que esperar do código de John - que outras partes da base de código ele entende bem e quais partes ele não faz, se ele é um guru de SQL ou um novato em GUI, etc. etc.

Executar o código de todos por meio de um formatador essencialmente exclui essas informações, ocultando-as atrás de um git blame , que você pode não se incomodar em executar.

    
por 14.09.2011 / 03:09
fonte
1

Reforçar o estilo de codificação uniforme é sempre difícil. Idealmente, essa tarefa mundana deve ser deixada para uma ferramenta para manipular. Eu aplaudo a comunidade de idiomas Go por fazer isso.

    
por 13.09.2011 / 21:20
fonte
1

É uma mistura de ambos. Só porque é um padrão não o torna legível e sustentável. Se ainda não houver um padrão instilado, ou se houver aspectos defeituosos e ilegíveis, a revisão é apropriada.

    
por 13.09.2011 / 23:06
fonte
0

Isso realmente depende muito do tipo de organização.

Se você é um pequeno grupo de super-heróis, qualquer tipo de estilo é bom. Se todos tiverem o seu próprio estilo, e forem bons e internamente consistentes, então é todo o processo que você precisa. Os super-heróis vão dizer: "Jane tem parênteses, então é isso que ela quer dizer" ou "Jack usa o camelCase para variáveis".

Os padrões universais tendem a ser os melhores para fazer de todos um player B +. Seus super-heróis serão derrubados por isso. Mas se você quiser que um jogador e meia dúzia de jogadores B e meia dúzia de jogadores em C calculem a média até o nível B +, então você quer padrões consistentes. Neste caso, você quer que todos façam as coisas da mesma forma que o jogador Um pode percorrer o código de todos o mais rápido possível.

Muitos de vocês, "Mas espere, por que não acabar com os jogadores B e C?"

A realidade é que não há muitos super-heróis. Embora possa pagar para encontrá-los e criá-los no Google, colocar um novo sistema de faturamento para a Ma Bell pode ser mais rentável com a última equipe. (E se você realmente tem super-heróis, 4 ou 5 deles serão duas vezes mais caros que uma dúzia de juniores)

    
por 24.03.2012 / 05:10
fonte