Vantagens e desvantagens da reformatação de código forçado

Atualmente, estou trabalhando em um local que pode estar forçando os desenvolvedores a usar um formatador de código automatizado no check-in de controle de versão. Estou procurando opiniões de desenvolvedores sobre as vantagens e desvantagens de fazer isso ... como você acha que isso ajudaria ou dificultaria os desenvolvedores. Meu caso específico envolve Java / JSPs, mas acho que a pergunta poderia se aplicar a qualquer linguagem.

Eu acho que é muito importante fazer isso. Aqui está o porquê:

• Isso faz com que as diferenças de controle de origem mostrem apenas as alterações reais do código e praticamente eliminam o "ruído de diferença" devido ao espaço em branco e outras opções de formatação insignificantes.
• Torna todo o código mais semelhante, para que os desenvolvedores se sintam mais confortáveis ​​em parear e compartilhar as bases de código

Se você fizer isso, eu recomendaria que todos fizessem o check-in de todo o código e, em seguida, uma pessoa reformate toda a base de código e depois faça o check-in novamente para que haja uma mudança "gigante" definida para formatação (que todos podem ignorar), mas depois disso, todos os diffs são diffs de código real.

Se você fizer isso pouco a pouco, estará misturando alterações reais de código com alterações de formatação e as coisas ficarão desnecessariamente confusas no local da mudança.

Vou dar minha própria resposta aqui, pois as pessoas parecem estar adicionando vantagens. O que vejo como desvantagens são:

• Elimina a capacidade de fazer 'melhor' do que o formatador automático ... ele desfaz sua formatação mais limpa. Um exemplo disso seria declarações de parâmetros baseados em colunas, listas de adições discretas de objetos etc.
• Cria uma resistência à alteração das convenções de estilo, pois agora elas criarão grandes alterações de diferenças enganosas.
• Remove a capacidade de fazer qualquer formatação de 'caso especial' em que um formato alternativo tornaria o código mais legível.
• Ele o vincula ao uso de IDEs que suportam exatamente os recursos de reformatação necessários. Em outro IDE, falta uma das opções necessárias, pois isso causará pelo menos alguns problemas.
• Torna-se problemático o compartilhamento de um repositório de códigos gravável com um grupo externo, a menos que eles usem exatamente as mesmas convenções de formato do seu grupo (geralmente, mas nem sempre).
• Sempre haverá exceções em que um formato ligeiramente diferente provavelmente é mais limpo que o estilo prescrito. A conversão automática pode, portanto, muitas vezes ocultar a intenção de certos blocos de código, o que é efetivamente tão bom quanto adicionar um defeito ao código.

Simplificando, um conjunto de convenções não automatizadas define os requisitos mínimos de estilo / legibilidade, onde as convenções automatizadas definem o mínimo e o máximo.

Lembro-me de olhar para o VB (versão 5, talvez) e encontrar uma das coisas mais irritantes sobre ele, que seria reformatar à força o meu código e remover coisas acima e além de sua formatação básica.

Acho que a formatação forçada de código é ótima. Ele permite que um desenvolvedor percorra todo o corpus de código sem ter seus olhos refletidos em todos os lugares. Ter esse padrão em vigor também ajuda os desenvolvedores iniciantes a quebrar maus hábitos.

A principal desvantagem é perder a formatação personalizada onde realmente importa.

Imagine uma verificação de sanidade típica se () falhar se alguma das condições específicas estiver presente, mas não for atendida ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Isso é legível graças ao recuo razoável, seguindo a estrutura lógica das condições.

Agora, sua ferramenta automatizada não tem idéia sobre a separação lógica de diferentes condições em linhas relacionadas. Não vê razão para que cada grupo de condições seja composto por 3-4 em uma linha e divida a próxima condição pela metade. Ou ele será dividido, uma expressão de comparação por linha. Pode até parecer mais bonito na tela, mas a lógica será perdida.

Eu adicionei uma resposta com desvantagens e apresentarei o que considero uma grande vantagem também.

Quando você usa uma reformatação automática de código no commit, ele realmente abre a possibilidade de variações de preferências pessoais sem o efeito usual de ter suas preferências infligidas a outras pessoas. Você pode ter seu código de formato IDE com um padrão comum na confirmação, mas exibi-lo no seu formato preferido sem afetar os outros.

Isso para mim é quase o Santo Graal da codificação baseada em convenções ... você obtém as vantagens de um formato de código comum, mas ainda permite que preferências pessoais sejam suportadas sem conflitos.

Depende das suas necessidades, mas algumas restrições são bastante úteis, por exemplo, todos os if () devem ser seguidos por chaves, pois é muito fácil entender isso se estiver refatorando.

Considere esse caso:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Se agora você deseja adicionar algum log ao caso if, pode escrever acidentalmente:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

E de repente seu método sempre retorna foo.

Editar: não está na formatação automática, mas na verificação de estilo. Desculpe se essa resposta também estava fora de tópico. :)

Isso ajuda muito a uniformizar o código na empresa e, graças a isso, você geralmente produz uma estrutura mais facilmente compreensível e facilmente mais fácil de manter para o seu produto.

Bem, as vantagens são o mesmo que qualquer formatador de código, como a padronização do código, semântica entre desenvolvedores, etc. As únicas possíveis desvantagens que eu vejo é a falta de um olho humano após a formatação, para adicionar algumas exceções, etc.
Então eu é melhor considerar um formatador IDE em vez de um formatador de horário de check-in.

Na minha experiência, é uma coisa boa. Sem um, as comparações de código geralmente mostram uma bagunça na formatação de espaço em branco e podem ocultar as alterações reais do código. Na minha experiência, mexer com a formatação de alguém não é o pecado que se faz, especialmente com os benefícios potenciais de consistência em toda a equipe.