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

Estou pensando em criar um trabalho cron que verifique o código, execute formatadores de código nele e, se algo mudou, confirma as alterações e as empurra de volta.

A maioria dos projetos que usam autoformatters os coloca em um git hook, mas fazê-lo automaticamente a cada poucas horas removeria a carga de cada desenvolvedor para instalar o git hook.

Eu ainda encorajaria todos a escreverem códigos limpos e bem formatados, e talvez eu possa fazer com que o sistema execute ping automaticamente nos desenvolvedores quando o código que eles escreverem for reformatado, para que eles saibam o que fazer no futuro.

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

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

Em vez disso, tentaria facilitar a aplicação de formatação automática de código de acordo com o padrão da sua equipe diretamente dentro do seu editor ou IDE , ao arquivo de código-fonte atual (ou partes selecionadas). Isso dá aos membros da sua equipe mais controle sobre como e quando a formatação ocorre, deixe-os inspecionar o código antes que ele seja confirmado na forma final e testá-lo após a formatação , não antes.

Se todos ou a maioria dos membros da sua equipe usam o mesmo editor, isso não deve ser muito difícil. Se todo mundo usa uma diferente, sua abordagem pode ser a segunda melhor solução, desde que a equipe suporte 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 do código.

É uma má idéia, não apenas porque desencoraja as pessoas de escrever código decente, mas também porque a reformatação será exibida como alterações de código no seu VCS (você usa uma que 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 alterações no código) tem a possibilidade de introduzir bugs, sejam manuais ou automatizados. Portanto, seu formatador agora pode introduzir bugs no seu código que não passarão por revisões de código, testes de unidade, testes de integração etc. até possivelmente meses depois.

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

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

Com o git , um gancho de pré-confirmação seria útil. Em muitos projetos C ou C ++ criados com algum Makefile , estou adicionando algum indentdestino (que executa adequadamente formatadores de código como indentou astyle) e espero que os colaboradores sejam executados make indentregularmente. BTW, você pode até adicionar algumas makeregras para garantir que os ganchos do git foram instalados (ou para instalá-los).

Mas, na verdade, é mais uma questão social do que técnica . Você deseja que sua equipe cometa 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 precisa.

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

Eu acho que é uma má ideia. Muitas das respostas já abordaram que ele suja a história, dificultando a identificação de quem realmente adicionou uma linha e que incentiva as pessoas a apenas cometerem o que quer que o bot de formato a manipule.

Uma abordagem melhor seria incorporar um verificador de formato em sua ferramenta de construção. (Em Java, existe o Checkstyle ). Depois, permita que as pessoas mesclem suas ramificações à ramificação principal se a construção for aprovada (incluindo a formatação).

Se você permitir que as pessoas se comprometam diretamente com a ramificação principal (como no Subversion, por exemplo), você ainda precisará garantir que todos tenham a disciplina de confirmar apenas o código formatado (ou que o servidor aceite apenas as confirmações depois que algumas verificações forem executadas) )

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

Da mesma forma que a recomendação do @ BasileStarynkevitch, usamos os ganchos de pós-recebimento do lado do servidor git para enviar "emails de aviso" sobre o estilo do código.

Se eu enviar um commit que contenha violações de estilo, o servidor de origem git me enviará um email informando que eu quebrei as diretrizes de estilo e recomendo que eu corrija meu código. No entanto, isso não é aplicado porque pode haver razões válidas para quebrar o estilo da casa (cadeias longas que excedem o limite de comprimento da linha, por exemplo).

Se é um problema sistêmico que está prejudicando a base de código, talvez seja hora de começar a apresentar problemas de estilo de código nas revisões de código. O estilo de código inadequado pode mascarar os erros e dificultar a leitura do código, por isso pode ser um problema válido de revisão de código.

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

Como o @DocBrown diz, outra opção é aplicar o estilo de código ao seu IDE. Usamos o CodeMaid com o Visual Studio para corrigir muitos erros de estilo comuns. 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 uma má ideia. Não me interpretem mal, o motivo para isso parece ótimo, mas o resultado ainda pode ser horrível.

Você terá conflitos de mesclagem ao puxar um galho rastreado. Pelo menos, acho que seria esse o caso, posso estar errado.

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

Na verdade, você pode apenas conferir um commit recente. Faça uma nova ramificação, cometa algo mesquinho, escolha cereja ou mescla sem confirmação automática.

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

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

Mas mesmo uma noite pode ser uma má ideia.

Você pode executá-lo semanalmente, quando tiver certeza de que não ocorrerão conflitos de mesclagem, pois tudo está concluído na segunda-feira.

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

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

Eu acho que fazer um script de instalação que crie automaticamente o repositório git e ajuste os ganchos para o projeto seria melhor.

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

Algo que eu não vi mencionado é o fato de que às vezes existem razões legítimas para não formatar algo de acordo com um conjunto de regras. Às vezes, a clareza do código é aprimorada, indo contra uma determinada diretriz de que 99% das vezes 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 péssima ideia.

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

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

E há a questão de que tipo de alterações o formatador de código faz. Uso a formatação automática no meu editor, funciona razoavelmente bem e posso melhorar quando a formatação automática é menos que perfeita. Se você usar um formatador de código que vai além disso, não melhorará o código, mas 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 assim provavelmente seria sugerido pelo tipo de desenvolvedor "grammer-nazi" (ortografia intencional) que deseja forçar seu estilo a todos os outros. Espere uma reação negativa e espere que os desenvolvedores flexíveis, normalmente descontraídos, aplaudam.

Você não menciona os VCS que usa, mas, dependendo dessa outra opção, é ter um gancho no 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 enviada e depois 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 desenvolvedores a enviar apenas código com a formatação desejada, incentivando-os a escrever código limpo desde o início, tornando os desenvolvedores responsáveis ​​por testar o código formatado corretamente e aliviando seus desenvolvedores de instalar manualmente um cliente gancho.

É uma troca entre um formato de código mais limpo e mais exato e 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 do git ou culpa em 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 desempenha um papel importante.

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

Uma opção é definir um alias (ou gancho, ou o que for) para a função de confirmação, 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 peça 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 idéia (dependendo de quanto você deseja empurrar esses padrões de codificação) é fazer com que o sistema envie um relatório de algum tipo quando a opção 2 está selecionada.

Pode ser um bom equilíbrio de verificar automaticamente todo o código que 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, conforme mencionado em outras respostas. Com o 'Revisei e aprove as correções de formatação automática; opção commit, ele ainda mantém a responsabilidade pessoal por cada desenvolvedor trabalhar e não mexe com o VCS.

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

A parte boa é que faz parte do projeto, para que todos os desenvolvedores o obtenham em seu projeto.

Como um bônus adicional, as fusões seriam significativamente simplificadas, já que as coisas não estarão dando voltas.

As revisões de código impedirão qualquer erro.

Outro lugar que eu faria é fazer parte da compilação. No meu caso, eu o tenho de tal forma que o maven builds reformata o XML e limpa os arquivos pom e reformata o código.

Dessa forma, quando os desenvolvedores estiverem prontos para enviar tudo será limpo para sua solicitação de recebimento.