Resumo

Este revisor de código com IA gratuito é, na prática, um verificador de pré-review baseado em regras. Cole um git diff ou um trecho e ele analisa as linhas adicionadas com treze regras que cobrem segredos escritos no código, SQL montado por string, exceções engolidas, testes desativados e restos de depuração. Também sinaliza mudanças grandes demais e falta de testes, e devolve uma nota de 0 a 100 com achados numerados por linha. Roda inteiramente no seu navegador, não usa modelo de IA e serve para resolver os problemas mecânicos antes da revisão humana.

Confira seu diff antes que um revisor faça isso

Cole um git diff ou um trecho de código. Este revisor de código com IA gratuito aponta segredos, SQL inseguro, exceções engolidas, código de depuração esquecido e mudanças grandes demais, tudo no seu navegador, e dá ao pull request uma nota de 0 a 100.

Verificar meu diff
Engineer reviewing a side-by-side code diff on a monitor

Verificador de diff pré-review

Cole um diff unificado ou qualquer código. Só as linhas adicionadas são verificadas quando um diff é detectado. Nada do que você colar sai do seu navegador.

--/100
Cole código para começar
Nada verificado ainda.
    Como funciona

    O que o verificador analisa, e o que ele ignora

    Só linhas adicionadas

    Se você colar um diff unificado, o verificador lê os cabeçalhos de hunk, conta os números de linha no arquivo novo e analisa apenas as linhas que você adicionou. Linhas removidas e o contexto inalterado nunca geram achado, então ninguém é culpado por código antigo.

    Nota ponderada por severidade

    São treze regras em três níveis. Alta custa 15 pontos: segredos escritos no código, eval, SQL montado por string e verificações TLS desligadas. Média custa 7: exceções engolidas, testes focados, innerHTML e um diff de 400 linhas. Baixa custa 2: TODOs, prints de depuração e código comentado. Cada regra conta no máximo três vezes.

    Verificações de tamanho e de teste

    Acima de 200 linhas adicionadas você recebe um aviso para dividir a mudança; acima de 400, um aviso mais firme. Isso segue o estudo da SmartBear sobre revisões da Cisco, que mostra que a qualidade da revisão cai quando o revisor enfrenta mais de 200 a 400 linhas por vez. Um diff com mais de 50 linhas adicionadas e sem arquivo de teste também é sinalizado.

    Como usar

    Do colar ao pull request limpo em quatro passos

    1. 1

      Cole seu diff

      Rode git diff main...HEAD, ou git diff --staged antes de fazer o commit, e cole a saída. Um trecho simples também funciona, mas você perde os nomes dos arquivos e a detecção de arquivos de teste.

    2. 2

      Leia primeiro os achados de alta severidade

      Os itens em vermelho são os que um revisor vai parar para analisar. Uma chave escrita em um commit permanece no histórico mesmo depois que você apaga a linha, então rotacione a chave em vez de só removê-la.

    3. 3

      Corrija ou justifique o resto

      Cada achado vem com uma correção em uma linha. Se um alerta for falso positivo, diga isso na descrição do PR. Assim você poupa o revisor da mesma pergunta.

    4. 4

      Copie o checklist

      O botão de copiar transforma os achados em um checklist em markdown que você pode colar no corpo do PR, para que o revisor veja o que você já encontrou.

    Por que uma pré-checagem

    Os primeiros trinta segundos de uma revisão não deveriam ser gastos com console.log

    Você abre um pull request de um colega e conhece a rotina. Passa pelo diff, encontra um print de depuração esquecido, um TODO sem ticket, um teste pulado e um catch que engole o erro. Nada disso precisa de um humano. Precisa de um checklist que rode antes de o pedido sair. É essa lacuna que a ferramenta preenche. A atenção de um revisor é limitada: o estudo da SmartBear sobre revisões da Cisco mostrou que a descoberta de defeitos se sustenta quando as pessoas revisam de 200 a 400 linhas em 60 a 90 minutos, e cai além disso. Cada minuto gasto com achados mecânicos é um minuto que não vai para as perguntas que só uma pessoa consegue responder: essa é a abordagem certa, ela se encaixa na arquitetura, ainda vai fazer sentido daqui a seis meses? Ela não substitui um revisor, e não finge substituir. Tira as objeções baratas para que a revisão humana comece pela parte interessante.

    • Pega os achados mecânicos antes de o pedido de revisão sair
    • Dá a cada achado um número de linha tirado dos cabeçalhos de hunk do diff
    • Roda localmente, então é seguro colar código proprietário
    Dois engenheiros discutindo uma mudança de código em um notebook
    FAQ

    Perguntas sobre o verificador

    É um revisor de código com IA ou um linter?
    Nenhum dos dois, estritamente. É um verificador de pré-review baseado em regras. Nenhum modelo lê seu código e nada é gerado. Treze regras de padrão analisam as linhas adicionadas em busca do que um revisor percebe nos primeiros trinta segundos: segredos, SQL montado por string, exceções engolidas e saída de depuração esquecida. Somos honestos sobre isso, porque um revisor de código com IA que adivinha é pior que um checklist que não adivinha.
    Meu código sai do navegador?
    Não. As verificações rodam em JavaScript nesta página. Não há upload, chamada de API nem conta. A única coisa registrada é um evento anônimo de que a ferramenta foi usada, sem nenhum conteúdo da caixa de texto.
    De onde vêm as regras de 200 a 400 linhas e de arquivo de teste?
    O limite de tamanho segue o estudo da SmartBear sobre dados de revisão da Cisco, que recomenda revisar no máximo de 200 a 400 linhas por vez. A regra de mudança pequena segue as práticas públicas de engenharia do Google para CLs pequenas. A regra de falta de teste é uma convenção nossa: um diff com mais de 50 linhas adicionadas e sem arquivo de teste recebe um alerta, porque é uma pergunta que revisores fazem de qualquer forma.
    Como a nota é calculada?
    Ela começa em 100. Cada achado subtrai pontos conforme a severidade: 15 para alta, 7 para média e 2 para baixa. Cada regra conta no máximo três vezes, para que uma regra barulhenta não zere a nota. É uma convenção para ordenar o trabalho, não uma medida de qualidade do código. Nota 100 significa que nenhuma regra disparou, não que o código está correto.
    O que ele não pega?
    Tudo que exige entendimento: lógica de negócio errada, condições de corrida, uma abstração ruim, uma API que não vai envelhecer bem. Regras baseadas em regex também geram falsos positivos, por exemplo um fixture de teste que contém uma senha falsa. Trate cada achado como uma pergunta a responder, não como um veredito.
    Com quais linguagens funciona?
    As regras são padrões de texto, então funcionam com JavaScript, TypeScript, Python, Java, Go e a maioria dos códigos da família C. Algumas regras são específicas de linguagem: except genérico é Python, System.out.println é Java, InsecureSkipVerify é Go. Cole um git diff unificado e os números de linha vêm dos cabeçalhos de hunk.
    É gratuito?
    Sim, sem cadastro. Se você quiser respostas sobre o resto do seu repositório enquanto revisa, como quem chama esta função ou onde um valor de configuração é lido, para isso existe o codebasechat.

    Revise com o repositório inteiro na tela

    Um diff mostra o que mudou, não o que essa mudança toca. O codebasechat responde perguntas sobre seu código em linguagem simples, para você conferir quem chama a função alterada antes de aprovar.

    Experimente o codebasechat grátis