Code Review em Rust: o que verificar e como dar feedback para iniciantes

Introdução: por que o code review em Rust é importante para iniciantes

Code review (revisão de código) é uma das formas mais eficazes de melhorar a qualidade do projeto e acelerar o aprendizado. Para a linguagem Rust, conhecida por seu sistema de tipos rigoroso e modelo único de ownership, a revisão deixa de ser uma formalidade e se torna uma necessidade. Desenvolvedores iniciantes frequentemente cometem erros que o compilador não detecta, mas que podem levar a bugs lógicos ou redução de desempenho.

Neste artigo, abordaremos o que observar ao fazer code review em Rust, como dar feedback útil e como não desmotivar um iniciante com críticas excessivas. O material será útil tanto para quem atua como revisor pela primeira vez quanto para quem deseja aprender a escrever código de maior qualidade.

1. Principais aspectos a verificar no código Rust

O code review em Rust deve abranger várias áreas-chave. Abaixo está um checklist para revisores iniciantes.

1.1. Ownership e Borrowing

Esta é a base do Rust. Mesmo que o código compile, ele pode conter clonagens desnecessárias ou uso incorreto de referências. Verifique:

\n
• Está sendo usado &str em vez de &String? (este último geralmente é desnecessário)
\n
• Existem .clone() desnecessários? Por exemplo, se a função aceita &T, não é necessário clonar os dados antes da chamada.
\n
• Os empréstimos estão sendo usados corretamente: &mut T apenas quando for necessário modificar os dados.
\n

// Ruim: clonagem desnecessária\nfn process(data: &Vec<String>) {\n    for item in data.clone() { // clone não é necessário\n        println!("{}", item);\n    }\n}\n\n// Bom: iteração por referência\nfn process(data: &[String]) {\n    for item in data {\n        println!("{}", item);\n    }\n}

1.2. Tratamento de erros

Rust não usa exceções, portanto o tratamento correto de erros é crítico. O que observar:

\n
• Estão sendo usados Result e Option em vez de pânico (.unwrap(), .expect())?
\n
• Há tratamento de erros com match ou operador ??
\n
• O contexto do erro não está sendo perdido? (é útil usar map_err ou tipos de erro personalizados)
\n

// Ruim: pânico ao ocorrer erro\nlet file = File::open("config.toml").unwrap();\n\n// Bom: propagação do erro com contexto\nfn read_config() -> Result<String, io::Error> {\n    let mut file = File::open("config.toml")?;\n    let mut contents = String::new();\n    file.read_to_string(&mut contents)?;\n    Ok(contents)\n}

1.3. Desempenho e alocações

Iniciantes frequentemente não pensam em alocações desnecessárias. Preste atenção a:

\n
• Uso de Vec onde um array de tamanho fixo ([T; N]) seria suficiente.
\n
• Criação de strings com format! dentro de loops — é melhor usar join ou push_str.
\n
• Otimização prematura: não critique micro-alocações se não estiverem em um caminho crítico.
\n

2. Como dar feedback: de forma suave, específica e construtiva

Code review não é uma competição, mas sim aprendizado. Sua função é ajudar o colega (ou você mesmo no futuro) a escrever melhor, e não mostrar o quão inteligente você é.

2.1. Regra do "Sanduíche" (elogio-crítica-elogio)

Comece com algo positivo: destaque que o código está bem estruturado ou que o autor usou corretamente o match. Em seguida, aponte o problema e sugira uma solução. Termine com uma frase encorajadora.

Exemplo: "Ótimo que você está usando Option em vez de pânico. Única observação: aqui você pode substituir .unwrap() por ? para evitar pânico em caso de erro. No restante, o código está excelente!"