Reviewing Logic and Correctness

Passo 1 — Ler cada função ou método alterado por inteiro

Não revisar apenas as linhas que mudaram (o diff highlight). Ler a função ou método completo para entender o comportamento antes e depois da mudança. O contexto das linhas não alteradas é frequentemente onde bugs se escondem.

Para cada unidade de código alterada, responder: qual era o comportamento anterior e qual é o comportamento novo?

### Passo 2 — Traçar todos os caminhos de controle

Para cada bloco de lógica alterado, traçar explicitamente todos os caminhos possíveis de execução:

- Caminho feliz (happy path): input válido, condições normais.

- Caminhos alternativos: condicionais que desviam o fluxo principal. - Caminhos de erro: exceções lançadas, returns antecipados, fallbacks. - Caminhos de borda: valores limite, listas vazias, zero, strings vazias.

Verificar se cada caminho produz o resultado correto e se nenhum caminho deixa o sistema em estado inválido.

Passo 3 — Verificar tratamento de nulo e estado inválido

Para cada variável, parâmetro ou resultado de operação que pode ser `null`, `undefined`, vazio ou inválido:

- Há verificação antes do uso?

- O tratamento de nulo está no lugar correto (perto da origem, não espalhado)? - Exceções lançadas por nulo são capturadas no nível adequado? - Valores padrão assumidos implicitamente estão corretos para todos os contextos de chamada?

Passo 4 — Verificar transformações de dados

Para operações que transformam dados (mapeamentos, cálculos, comparações, serializações):

- A transformação preserva semântica — o valor resultante significa o que deveria?

- Tipos são compatíveis em cada operação (sem coerção implícita inesperada)? - Comparações de igualdade usam o operador correto (referência vs. valor, case sensitivity)? - Arredondamento, truncamento ou overflow são tratados em cálculos numéricos? - Datas e timezones são tratados consistentemente?

Passo 5 — Verificar contratos de interface

Para cada ponto em que o código alterado chama ou é chamado por outros módulos:

- A assinatura da função/método está sendo usada corretamente por todos os chamadores?

- O tipo e formato do retorno estão conforme o contrato (não apenas no happy path)? - Exceções lançadas estão documentadas ou são inesperadas para os chamadores? - Mudanças no contrato são backwards-compatible ou há breaking change não sinalizado?

Passo 6 — Verificar condições de corrida (código concorrente)

Quando o código alterado envolver operações assíncronas, threads, filas ou acesso compartilhado a estado:

- Há operações que assumem ordem de execução que não é garantida?

- Estado compartilhado está sendo acessado sem sincronização adequada? - Há time-of-check-to-time-of-use (TOCTOU) vulnerability: verificar condição e agir em operações separadas não atômicas? - Promessas ou Futures rejeitadas estão sendo tratadas?

---