Existe justificativa para deixar marcadores de conflito no código de check-in?

14

Considere marcadores de conflito. ou seja:

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

No caso particular que me motivou a postar esta questão, o membro da equipe responsável havia acabado de concluir uma fusão do upstream para nossa filial e, em alguns casos, os deixou como comentários, como uma espécie de documentação sobre o que tinha acabado de ser resolvido. Ele deixou em um estado compilado, testa passando, então não é tão ruim quanto você imagina.

Instintivamente, eu realmente me opus a isso, no entanto, sendo demônios advogando para mim mesmo, eu posso ver porque ele poderia ter feito isso:

  • porque destaca para outros desenvolvedores de equipe o que foi alterado como resultado da mesclagem.
  • porque aqueles que são mais especializados com as partes específicas do código podem, então, abordar as preocupações ilustradas pelos comentários para que ele não precise adivinhar.
  • porque a mesclagem upstream é um problema e pode ser difícil justificar o tempo para resolver tudo bem e completamente, então algum aviso FIXME semi-completo é necessário, então por que não usar o conflito original como um comentário para documentar isso? .

Minha objeção foi instintiva, mas gostaria de poder justificá-la racionalmente ou ver minha posição mais sabiamente. Alguém pode me dar alguns exemplos ou até mesmo experiências em que as pessoas tiveram um mau tempo com alguém fazendo isso e / ou razões por que é uma prática ruim (ou você pode bancar o advogado do diabo e apoiá-lo).

Minha preocupação imediata era que seria claramente irritante se eu estivesse editando um dos arquivos em questão, fizesse as alterações, obtivesse conflitos reais, mas também incluísse os comentários. Então eu teria um arquivo muito confuso. Felizmente isso não aconteceu.

    
por Benedict 25.10.2011 / 19:38
fonte

4 respostas

27

Isso está claramente errado. É o trabalho do sistema de controle de versão acompanhar as mudanças, e é o trabalho das ferramentas de comparação mostrar o que mudou como resultado da fusão. Deve haver um comentário no log de confirmação e, talvez, no código, explicando o que foi alterado e por quê. No entanto, IMHO, deixando os marcadores de conflito como comentários é o mesmo que deixar o código morto ao redor.

    
por 25.10.2011 / 20:04
fonte
5

Eu tive um problema semelhante com algum código sendo comentado (o que é de alguma forma similar ao seu caso) ou movido para um método que não está sendo chamado em lugar algum. Quando perguntado por que as pessoas fazem isso, a resposta é que elas se sentem um pouco mais seguras quando ainda há algum bloqueio de código. O contra-argumento mais óbvio é que é um trabalho de VCS e não deles. No entanto, há também outro aspecto. Quando alguém está lendo código enquanto aprende ou faz alterações, ele provavelmente ficará paralisado por tal comentário. Ele definitivamente vai ler e talvez gastar algum tempo para entender por que está aqui e qual a possível correlação que tem com seu trabalho atual. Como um marcador de conflito é um sinal de conflito, que já foi resolvido, isso é uma perda de tempo.

    
por 25.10.2011 / 21:20
fonte
4

Acho que os comentários devem se referir ao código que está lá, não ao código que já existiu no passado, nem aos eventos que aconteceram com o código em algum momento do passado, nem ao código que existia em um universo paralelo (outro ramo ) no passado. Deixar os marcadores na maneira como seu membro da equipe criou pelo menos três problemas:

  1. O código original provavelmente era algo como blah blah null , e o relatório de erros dizia: "Não é possível usar null, use isto ou aquilo, ou o que for." Então, duas pessoas independentemente consertaram o bug e quando as correções foram mescladas, o conflito surgiu. Agora o comentário documenta não qual era o problema nem qual a correção corrigida, mas apenas que havia duas correções diferentes em algum momento no passado. Isso não é muito útil. Um comentário como //blah blah needs a non-null argument daria pelo menos uma indicação do que mudou (e até mesmo essa informação é mais facilmente disponível a partir do comentário de commit do sistema de controle de versão).
  2. A versão mesclada pode nem parecer com uma das linhas originais. Talvez se você quiser que o blá-blá leve isto e aquilo, a forma correta é blah blah (this,that) ou até algo mais complicado. Nesse caso, deixar a mensagem de conflito como um comentário certamente confundirá qualquer um que tentar ler o código mais tarde.
  3. A maioria dos sistemas de controle de versão oferece acesso ao histórico do projeto. Por exemplo, eu posso clicar com o botão direito em um arquivo no eclipse (com svn), dizer "Show History ..." e então dizer "Compare Current with ..." e obter uma janela de diferenças que realce as diferenças. mais fácil de grok se os destaques do diff contiverem as diferenças reais, e não os comentários em torno deles.Todas as alterações não funcionais no código dificultam a interpretação da leitura.
por 26.10.2011 / 15:16
fonte
-1

How annoying are conflict markers in checked-in code?

Tão irritante.

    
por 26.10.2011 / 18:29
fonte