Comparar dois textos para descobrir o que mudou é uma das tarefas mais recorrentes de quem revisa código, contratos, configurações ou respostas de API. Um comparador (ou diff) destaca linhas adicionadas, removidas e alteradas, poupando você de reler tudo. Neste guia você entende como funciona o diff, a diferença entre comparação de texto e semântica, como comparar JSON sem ruído e quando ignorar espaços e maiúsculas. Para comparar agora, use o comparador de texto, que roda no navegador.
Resposta rápida
- Diff mostra o que mudou: linhas adicionadas, removidas e alteradas (algoritmo LCS).
- Para comparar JSON sem ruído, formate os dois lados com a mesma indentação antes.
- Em objetos JSON, a ordem das chaves não muda o significado, mas muda o texto.
- Não compare dados sensíveis em sites que enviam o conteúdo a um servidor.
O que é diff
Diff vem de difference. A ferramenta pega duas versões, A (original) e B (nova), e calcula o menor conjunto de mudanças que transforma A em B. O algoritmo clássico é a maior subsequência comum (LCS): ele encontra as linhas que se mantêm em comum e, a partir delas, deduz o que entrou e o que saiu. É o mesmo princípio por trás do Git e das revisões de pull request.
Comparação de texto x comparação semântica
A comparação de texto trata o conteúdo como uma sequência de linhas e caracteres. É rápida e funciona para qualquer texto, mas não entende significado. A comparação semântica conhece a estrutura do formato: em JSON, ela sabe que a ordem das chaves não muda o objeto; em XML, que certos nós são equivalentes. Como a maioria das ferramentas faz comparação de texto, o truque para aproximar do semântico é normalizar antes, por exemplo formatando o JSON dos dois lados.
Como comparar JSON com formatação
Imagine dois JSON com o mesmo conteúdo, mas um em uma linha e outro indentado. Uma comparação de texto pura acusaria diferenças em quase todas as linhas, embora o conteúdo seja igual. A solução é formatar ambos com a mesma indentação antes de comparar. Aí o diff destaca apenas o que mudou de verdade: um valor diferente, uma chave nova, um item removido de um array. Para isso, use o formatador de JSON antes, ou marque a opção de formatar JSON no próprio comparador.
Linha adicionada, removida e alterada
Entender a marcação evita interpretações erradas:
- Adicionada: aparece só na versão B (a nova).
- Removida: existia em A e não está mais em B.
- Alterada: uma linha de A foi trocada por uma de B na mesma posição.
- Igual: mantida nas duas versões, sem destaque.
A contagem desses tipos dá uma medida rápida do tamanho da mudança, útil em revisões e em registros de alteração.
Ignorar espaços e maiúsculas: quando usar
Nem toda diferença importa. Ao comparar textos vindos de fontes diferentes, ignorar espaços evita que recuos e múltiplos espaços contem como mudança. Ignorar maiúsculas ajuda quando a caixa não é relevante. Em código, porém, avalie com cuidado: em muitas linguagens a indentação ou a caixa têm significado, então comparar de forma sensível pode ser o correto. Use as opções conforme o objetivo da revisão.
Casos de uso comuns
- Código: revisar o que mudou antes de aprovar uma alteração.
- Configuração: conferir diferenças entre ambientes (dev e produção).
- Contrato e documento: identificar cláusulas alteradas entre versões.
- Payload de API: comparar a resposta esperada com a recebida.
- Documentação: ver o que foi atualizado entre revisões.
Exemplo prático
Compare estes dois textos. Versão A:
nome: Joao
plano: básico
ativo: trueVersão B:
nome: Joao
plano: premium
ativo: true
desconto: 10O diff mostra a linha do plano como alterada (de básico para premium) e a linha de desconto como adicionada. As demais permanecem iguais. Em poucos segundos você sabe exatamente o que mudou.
| Granularidade | O que destaca | Melhor para |
|---|---|---|
| Por linha | A linha inteira que mudou | Código e configuração |
| Por palavra | As palavras alteradas na linha | Textos corridos, documentação |
| Por caractere | Cada caractere que mudou | Diferenças mínimas, contratos |
Diff por linha, por palavra e por caractere
Nem todo diff funciona na mesma granularidade. O mais comum é o diff por linha, que marca a linha inteira como mudada quando qualquer parte dela difere. É rápido e suficiente para a maioria das revisões de código e configuração. O diff por palavra ou por caractere mostra exatamente o que mudou dentro de uma linha, o que ajuda em textos corridos, como contratos e documentação, onde uma linha pode ser longa e a alteração, mínima.
Saber a granularidade explica um comportamento que às vezes confunde: em um diff por linha, trocar uma única palavra faz a linha aparecer como removida e a nova como adicionada, ou como uma linha alterada. Isso não é erro, é a forma como o algoritmo representa a substituição. Quando você precisa enxergar a diferença palavra a palavra, vale usar uma ferramenta com esse modo ou quebrar o texto em linhas menores antes de comparar.
Outra prática útil é normalizar os dois lados antes da comparação: padronizar quebras de linha, remover espaços ao final e, no caso de JSON, formatar com a mesma indentação. Quanto mais parecida a forma, mais o diff destaca apenas o conteúdo que realmente mudou, reduzindo o ruído e o tempo de revisão. Essa disciplina é o que separa uma revisão tranquila de uma cheia de falsos positivos.
Diff em revisões de código e merges
No desenvolvimento, o diff é o coração da revisão de código. Antes de aprovar uma mudança, a pessoa revisora lê o diff para entender o impacto: o que foi adicionado, removido e alterado. Diffs pequenos e focados são mais fáceis de revisar do que mudanças enormes, por isso é boa prática dividir alterações grandes em partes menores. Formatar o código antes de commitar também ajuda, porque evita que diferenças de estilo poluam o diff e escondam a mudança real.
Em merges, o diff aparece de novo quando há conflito: duas pessoas mudaram a mesma região e o sistema não sabe qual versão manter. Entender a marcação de adicionado e removido é o que permite resolver o conflito com segurança, escolhendo as linhas certas de cada lado. Mesmo fora do Git, comparar a versão antiga e a nova de um arquivo de configuração antes de aplicar em produção evita surpresas, como uma variável removida sem querer.
Uma dica final é cuidar das quebras de linha invisíveis. Arquivos criados no Windows usam um caractere de retorno diferente dos criados em Linux e Mac, e isso pode fazer um diff acusar que todas as linhas mudaram, mesmo quando o conteúdo é idêntico. Boas ferramentas normalizam essas quebras antes de comparar. Se um diff parecer mostrar diferenças demais sem explicação, desconfie de codificação ou de quebra de linha, e padronize os dois lados antes de concluir que houve mudança real.
Quando usar a ferramenta do ValorFinal
Use o comparador de texto para comparar dois textos, JSON ou trechos de código, com opções de ignorar espaços e maiúsculas e de formatar JSON antes. Para padronizar a entrada, use o formatador de código e o validador de JSON. Conheça as demais ferramentas de tecnologia.
Fontes oficiais
- Maior subsequência comum (LCS): algoritmo por trás do diff.
- Git (git diff): documentação do diff no controle de versão.
Conclusão
Comparar textos e JSON com um diff economiza tempo e evita erros em revisões. O segredo é normalizar antes (formatar JSON, padronizar quebras de linha e codificação) para o diff destacar só o que mudou de verdade. Use o comparador de texto, padronize a entrada com o formatador de código e conheça as demais ferramentas de tecnologia.