Seria uma má ideia executar periodicamente formatadores de código em um repositório?

Parece legal, mas eu preferiria ter pessoas responsáveis por cometer alterações de código, não bots.

Além disso, você quer ter absoluta certeza de que essas mudanças não quebram nada. Por exemplo, temos uma regra que ordena propriedades e métodos em ordem alfabética. Isso pode ter um impacto na funcionalidade , por exemplo, com a ordem dos dados e dos métodos nos arquivos WSDL dos contratos do WCF.

Em vez disso, eu tentaria tornar realmente fácil para todos na equipe aplicar a formatação automática de código de acordo com o padrão da sua equipe diretamente dentro de seu editor ou IDE , para o arquivo de código-fonte atual (ou selecionado partes dele). Isso dá aos membros de sua equipe mais controle sobre como e quando a formatação ocorre, deixá-los inspecionar o código antes que ele seja confirmado na forma final e testá-lo após a formatação ocorrer , não antes.

Se todos ou a maioria dos membros de sua equipe usarem o mesmo editor, isso não deve ser muito difícil. Se todos usarem um diferente, sua abordagem pode ser a segunda melhor solução, desde que a equipe ofereça suporte a isso. No entanto, eu recomendo que você tenha medidas extras de segurança instaladas, como compilações noturnas e testes automatizados que são executados após cada modificação automática de código.

É uma má ideia, não apenas porque desencoraja as pessoas a escrever código decente, mas também porque a reformatação aparecerá como alterações de código no seu VCS (você usa um que eu espero), mascarando o fluxo histórico do desenvolvimento do código . Pior ainda, toda ação de formatação de código (na verdade, todas as mudanças no código) tem a possibilidade de introduzir erros, seja manual ou automatizado. Assim, seu formatador pode agora introduzir erros em seu código que não passarão por revisões de código, testes de unidade, testes de integração, etc., possivelmente até meses depois.

Eu tenderia a acreditar que é uma boa idéia (para executar automaticamente os formatadores de código), mas essa é apenas a minha opinião.

Eu não os executarei periodicamente, mas, se possível, antes que o controle de versão seja confirmado.

Com git , um pre-commit hook fazendo isso seria útil. Em muitos projetos C ou C ++ construídos com alguns Makefile , estou adicionando alguns indent target (que executam formatadores de códigos como indent ou astyle ) e espere que os contribuidores executem make indent regularmente. BTW, você pode até mesmo adicionar algumas regras make para garantir que os ganchos git tenham sido instalados (ou para instalá-los).

Mas, na verdade, é mais uma questão social do que uma técnica . Você quer que sua equipe faça um código limpo e bem formatado, e essa é uma regra social do seu projeto. (Nem sempre há uma resposta técnica para todos os problemas sociais).

O controle de versão é principalmente uma ferramenta para ajudar na comunicação entre desenvolvedores humanos (incluindo você mesmo daqui a alguns meses). Seu software não precisa de VC ou formatação, mas sua equipe o faz.

BTW, diferentes comunidades e diferentes linguagens de programação têm visões diferentes sobre formatação de código. Por exemplo, o Go tem apenas um estilo de formatação de código, mas C ou C ++ tem muitos deles.

Eu acho que é uma má ideia. Muitas das respostas já cobriram que sujam o histórico, tornando difícil definir quem realmente adicionou uma linha e que isso incentiva as pessoas a apenas confirmar o que quer que seja e o format-bot vai lidar com isso.

Uma abordagem melhor seria incorporar um verificador de formato à sua ferramenta de criação. (No Java há Checkstyle ) Então, permita que as pessoas mesclem suas ramificações para o ramo principal se a construção passar (incluindo a formatação) .

Se você permitir que as pessoas se comprometam diretamente com o ramo principal (como no Subversion, por exemplo), você ainda precisará garantir que todos tenham a disciplina para confirmar apenas o código formatado (ou fazer com que o servidor aceite somente os commits depois de alguns cheques foram executados).

Em geral, acho que é uma má ideia. Em princípio, é uma ideia válida, mas pode ser problemática na realidade. Ter o formatador de código quebrando seu código é uma possibilidade real, e é necessária apenas uma formatação para que seus desenvolvedores respondam com hostilidade (provavelmente justificada) (por exemplo, "Seu formatador de código ruim quebrou a compilação, desligue-o agora! ").

Na mesma linha que a recomendação do @ BasileStarynkevitch, usamos git postserver-receive do lado do servidor para enviar "e-mails de consultoria" sobre o estilo de código.

Se eu enviar uma confirmação que contém violações de estilo, o servidor de origem do git me enviará um e-mail informando que eu quebrei as diretrizes de estilo e recomenda que eu corrija meu código. No entanto, isso não é obrigatório, pois pode haver motivos válidos para quebrar o estilo da casa (por exemplo, strings longas que excedem o limite de comprimento da linha).

Se é um problema sistêmico que está prejudicando a base de código, talvez seja hora de começar a trazer problemas de estilo de código nas revisões de código. O estilo de código inadequado pode mascarar bugs e tornar o código mais difícil de ler, portanto, pode ser um problema válido de revisão de código.

Para adicionar ao aspecto "problema social" das coisas, pode valer a pena incentivar as pessoas a corrigir defeitos cosméticos e estilísticos à medida que as encontrarem. Temos uma mensagem de confirmação padrão "Cosmética". para correções de estilo de código que outros desenvolvedores sabem que não contêm alterações significativas.

Como diz @DocBrown, outra opção é reforçar o estilo de código dentro do seu IDE. Nós usamos o CodeMaid com o Visual Studio para corrigir muitos erros comuns de estilo. Ele será executado ao salvar os arquivos de código, o que significa que o código de estilo ruim nunca deve entrar no repositório ... em teoria: -).

Sim, acho que é uma má ideia. Não me entenda mal, a razão para isso parece ótimo, mas o resultado ainda pode ser horrível.

Você terá conflitos de mesclagem ao extrair uma ramificação controlada, pelo menos temo que esse seja o caso, mas posso estar errado.

Eu não quero testá-lo agora mesmo no trabalho, mas você mesmo deve testá-lo.

Na verdade, você pode apenas verificar um commit recente. Faça um novo branch, faça algo insignificante, escolha picareta ou mescle sem autocommit.

Em seguida, execute seu script, puxe e se o resultado for uma confusão horrível, você definitivamente não deve fazer isso à luz do dia.

Em vez disso, você poderia colocá-lo em uma compilação noturna ou em uma compilação semanal.

Mas até uma noite pode ser uma má ideia.

Você pode executá-lo semanalmente, quando tiver certeza de que não haverá conflitos de mesclagem, porque tudo está terminado na segunda-feira.

Caso contrário, execute-o 1-2 vezes por ano nas festas de final de ano, quando conflitos de mesclagem não ocorrerão.

Mas a solução pode depender da sua prioridade para o estilo de código.

Acho que criar um script de configuração que cria automaticamente o repositório git e define os ganchos para o projeto seria melhor.

Ou você pode incluir o script de configuração do gancho em uma pasta para seus desenvolvedores dentro do projeto e simplesmente verificá-lo no próprio git.

Algo que eu não vi mencionado é o fato de que às vezes há razões legítimas para não formatar algo de acordo com um conjunto de regras. Às vezes, a clareza do código é melhorada indo de encontro a uma diretriz dada que 99% do tempo faz sentido. Os humanos precisam fazer essa ligação. Nesses casos, a formatação automática de código acabaria tornando as coisas menos legíveis.

É uma ideia terrível.

Se um dos meus colegas desenvolvedores fizesse alterações gratuitas nos arquivos de origem, ele não passaria em uma revisão de código. Isso só torna a vida mais difícil para todos. Mude o código que precisa mudar, nada mais. Mudanças sem sentido levam a conflitos de mesclagem, o que pode levar a erros e apenas criar um trabalho sem sentido.

Se você quiser fazer isso regularmente, isso é horrível.

E então há a questão de que tipo de mudanças o formatador de código faz. Eu uso formatação automática no meu editor, funciona razoavelmente bem, e eu posso melhorar as coisas quando a formatação automática é menos que perfeita. Se você usar um formatador de código que vá além disso, você não vai melhorar o código, você vai piorar.

E depois há o problema social. Há pessoas que querem forçar todos a usar seu estilo de código, e há pessoas mais flexíveis. Algo como isso provavelmente seria sugerido pelo tipo de desenvolvedor "gram-nazista" (ortografia intencional) que deseja forçar seu estilo em todo mundo. Espere uma reação negativa e espere que os desenvolvedores flexíveis, normalmente fáceis de usar, fiquem de pé.

Você não menciona o VCS que você usa, mas dependendo de que outra opção é ter um gancho do lado do servidor. Um VCS como o git suporta isso. Você pode instalar um gancho do lado do servidor que executa o formatador na versão que está sendo pressionada e, em seguida, compara o arquivo formatado com a versão que está sendo enviada. Se eles diferirem, o desenvolvedor não usou a formatação correta e o servidor pode rejeitar o envio. Isso forçaria seus devs a somente empurrar código com a formatação desejada, encorajando-os a escrever código limpo desde o início, isso tornaria os desenvolvedores responsáveis por ter testado o código formatado corretamente e dispensar seus desenvolvedores de instalar manualmente um lado do cliente. gancho.

É um trade-off entre um formato de código mais limpo e mais exato e mais fácil de entender o histórico do git. Depende da natureza do seu projeto e com que frequência você mergulha na história ou culpa para entender o que está acontecendo. Se você está trabalhando em algo novo e não precisa manter a compatibilidade com versões anteriores, o histórico geralmente não tem um papel importante.

Essa ideia é semelhante a algumas outras respostas, mas não posso comentar minhas sugestões.

Uma opção é definir um alias (ou hook, ou qualquer outro) para a função commit, que executa o formatador de código no código a ser confirmado antes de ser confirmado.

Pode ter 2 (ou mais) resultados:

1) Mostre ao usuário as alterações propostas e solicite sua aprovação para aplicar e confirmar as alterações.

2) Ignore as alterações propostas e confirme o código original.

Você também pode adicionar mais flexibilidade a essas opções, como a capacidade de editar as alterações propostas na opção 1. Outra ideia (dependendo de quanto você deseja forçar esses padrões de codificação) é fazer com que o sistema envie um relatório de algum tipo quando a opção 2 é selecionada.

Isso pode ser um bom equilíbrio na verificação automática de todos os códigos, como você deseja, enquanto ainda permite flexibilidade aos desenvolvedores para atender às suas necessidades. Também permite a opção de não 'rejeitar automaticamente' o código com diferenças de formatação, como mencionado em outras respostas. Com o 'Eu revi e aprove as correções automáticas de formatação; Cometer 'opção, ele ainda mantém a responsabilidade pessoal para cada trabalho de desenvolvedores e não mexer com VCS.

Eu não farei isso no repositório, mas farei isso salvo se a ferramenta suportar. Eclipse é um e, além disso, eu faria a limpeza do código, incluindo a classificação.

A parte boa é que é parte do projeto, então todo desenvolvedor vai buscá-lo para o projeto.

Como um bônus adicionado, as fusões seriam significativamente simplificadas, já que as coisas não vão estar pulando.

As revisões de código impedem quaisquer erros.

Outro lugar que eu faria seria fazer parte da compilação. No meu caso, eu tenho isso de tal forma que maven builds irá reformatar o XML e limpar arquivos pom e reformatar o código.

Dessa forma, quando os desenvolvedores estiverem prontos para executá-lo, todos serão limpos para sua solicitação de recebimento.