Code review em inglês: como comentar sem soar grosseiro
Em inglês, "Change this" soa muito mais duro do que "Mude isso" em português. Veja como pedir alteração, discordar e responder crítica sem estragar a relação com o time.
Em português, "Mude isso para um map" é um comentário normal de revisão. Traduzido ao pé da
letra — "Change this to a map." — vira uma ordem em inglês. É o desencontro que
mais custa relação a quem entra num time internacional: o comentário está tecnicamente certo e mesmo
assim cria atrito.
A norma em code review em inglês é o hedging: transformar a ordem em pergunta ou
sugestão. Compare os dois lados abaixo.
A fórmula que resolve quase tudo
Pergunta + motivo."Could we use a map here? It would eliminate the nested loop."
A pergunta devolve a decisão ao autor; o motivo justifica o pedido. E marque sempre se o comentário
é blocking (precisa mudar) ou non-blocking (sugestão).
Termos que aparecem neste guia
Consulte estas definições antes de avançar para os exemplos.
pull request (PR)
Pedido para revisar uma alteração antes de ela ser incorporada à linha principal do código.
merge
Ato de incorporar as alterações de uma branch em outra, normalmente depois da aprovação.
map
Estrutura de dados que associa uma chave a um valor; neste guia, não significa mapa geográfico.
nested loop
Laço de repetição executado dentro de outro laço, o que pode aumentar bastante o trabalho realizado.
hedging
Uso de perguntas e expressões de cautela para apresentar uma opinião sem transformá-la numa ordem absoluta.
draft
Pull request ainda em elaboração, aberto para compartilhar o trabalho antes de pedir aprovação final.
API key
Credencial secreta usada por uma aplicação para se identificar ao acessar uma API.
logs
Registros produzidos pelo sistema para acompanhar eventos, erros e o caminho de uma requisição.
regex
Expressão regular: padrão textual usado para localizar, validar ou substituir trechos de texto.
codebase
Todo o conjunto de arquivos e código-fonte que forma um projeto.
O mesmo comentário, dos dois jeitos
Compare as duas versões abaixo e toque na recomendada para ouvir.
Pedir uma mudança
✗ Change this to a map.
Troque isto por um mapa de chave e valor.
Poderíamos usar um mapa de chave e valor aqui? Isso eliminaria o laço aninhado.
A pergunta devolve a decisão ao autor e o motivo justifica o pedido. O imperativo sozinho soa como ordem de quem manda.
Apontar um bug
✗ This is wrong.
Isto está errado.
Acho que isso falha quando a lista está vazia — o índice ficaria fora do intervalo válido.
Descreva o cenário que quebra, não o julgamento. O autor consegue verificar em dez segundos e ninguém precisa defender nada.
Sugerir sem bloquear
✗ Rename this variable.
Renomeie esta variável.
Detalhe opcional: `d` poderia ser `daysLeft` — não impede a integração.
O prefixo "nit" avisa que é preferência e "non-blocking" libera o merge. Sem isso, o autor não sabe se pode seguir.
Perguntar sem acusar
✗ Why did you do it like this?
Por que você fez assim?
O que levou você a tratar a nova tentativa aqui, em vez de no cliente?
"Why did you" soa a cobrança. Perguntar pelo caminho ("what led you to") pede a razão sem sugerir que houve erro.
Discordar do revisor
✗ No, you are wrong.
Não, você está errado/errada.
Talvez me falte contexto, mas a transação já cobre isso. Quer que eu adicione um teste para deixar explícito?
Assumir que pode faltar contexto seu abre espaço para o outro recuar sem perder a face — e a oferta de teste encerra a discussão com algo concreto.
Elogiar
✗ Ok.
Certo.
Boa observação sobre o tratamento do fuso horário — eu não teria percebido.
Elogio específico é norma em revisão de time internacional. Ele equilibra a crítica e custa uma linha.
O vocabulário da revisão
LGTM— Está bom para mim
Looks good to me. Aprovação curta, informal. Em revisão delicada, escreva a aprovação por extenso.
nit— detalhe opcional
Abreviação de nitpick. Marca um comentário pequeno, geralmente de estilo, que o autor pode ignorar.
blocking— bloqueia o merge
Precisa mudar antes de integrar: bug, risco ou quebra de contrato.
non-blocking— não bloqueia
Sugestão. Dizer qual é qual poupa uma rodada inteira de revisão.
request changes— pedir alterações
O botão que trava o merge. Use quando há blocking de verdade — travar por estilo irrita.
out of scope— fora do escopo
Resposta legítima a um pedido que não pertence a esta alteração. Abra um ticket separado.
Onde é seguro ser direto
Hedging demais também erra: um comentário cheio de rodeio fica ilegível e o autor não descobre o que
precisa fazer. Seja direto quando houver risco real — segurança, perda de dados,
quebra de contrato público: "This leaks the API key into the logs — blocking." (Isto expõe a chave da API nos registros — impede a integração) Ninguém vai
achar isso rude; vão achar responsável.
A regra prática: suavize a opinião, nunca o fato. "Acho que este
nome ficaria melhor" pede rodeio. "Isto vaza a chave" não pede.
Como escrever a descrição do pull request
Três parágrafos curtos resolvem: o que mudou, por que e
como testar. A justificativa é o que os revisores mais sentem falta — o código já mostra
o "o que". Se a alteração for grande, avise onde começar a ler: "Start with the migration, the
rest follows from it." (Comece pela migração; o restante decorre dela)
Marque o que ainda está em andamento como draft, e diga se você quer revisão de arquitetura
ou só de detalhe: "Looking for feedback on the approach, not the naming yet." (Quero comentários sobre a abordagem; os nomes ainda não são o foco) Isso muda
completamente o tipo de comentário que você recebe.
Erros de tradução literal que aparecem em revisão
"I have doubt about this" — em inglês, doubt é desconfiança, não dúvida.
O certo é "I have a question about this" (Tenho uma pergunta sobre isso). "Explain me this function" precisa da
preposição: "explain this function to me" (explique esta função para mim). E a dupla negativa
("I didn't understand nothing") inverte o sentido em inglês padrão — use
"I didn't understand anything" (Não entendi nada).
?Por que meu comentário de code review soa grosseiro em inglês?
Porque o imperativo puro ("Change this", "Use a map here") carrega uma ordem em inglês que a tradução direta do português não carrega. A norma é o hedging: "Could we…?", "What do you think about…?", "I'd suggest…".
?Colocar "please" no fim resolve?
Não. "Fix this, please" continua sendo uma ordem — só uma ordem educada. O que suaviza é transformar a ordem em pergunta ou sugestão, não acrescentar uma palavra.
?O que significa "nit" num comentário?
É a abreviação de nitpick: um comentário menor, de estilo ou preferência, que não bloqueia a aprovação. Prefixar com "nit:" avisa o autor de que ele pode ignorar.
?Qual a diferença entre blocking e non-blocking?
Blocking é o que precisa mudar antes do merge (bug, risco, quebra de contrato). Non-blocking é sugestão. Dizer qual é qual poupa uma rodada inteira de revisão.
?Como discordar de um revisor sem criar atrito?
Assuma que pode faltar contexto seu antes de defender: "I might be missing something, but the transaction already covers that case — want me to add a test to make it explicit?". Ofereça uma saída junto com a discordância.