Code Review em C++: o que verificar e como dar feedback

Introdução: por que o Code Review é necessário em C++

Code review (revisão de código) é uma das práticas-chave do desenvolvimento profissional. No mundo do C++, onde erros de gerenciamento de memória ou uso incorreto da STL podem levar a bugs difíceis de detectar e vazamentos, uma revisão de qualidade se torna criticamente importante. Não se trata apenas de verificar estilo, mas de uma busca sistemática por problemas potenciais: desde erros lógicos até violações de RAII (Resource Acquisition Is Initialization).

Neste artigo, vamos abordar o que observar ao fazer code review de código C++, como formular comentários para que sejam úteis e não ofensivos, e como implementar uma cultura de revisão saudável na equipe.

O que verificar ao fazer Code Review de código C++

Revisão não é ler código como um livro. É uma análise ativa. Use a seguinte lista de verificação para não perder nada importante.

1. Segurança no gerenciamento de memória e RAII

C++ não perdoa descuidos com recursos. Verifique:

• Se estão sendo usados smart pointers (std::unique_ptr, std::shared_ptr) em vez de new/delete puros.
• Se não há vazamentos de memória quando o código usa raw pointers em cenários complexos.
• Se o princípio RAII é respeitado: todos os recursos (arquivos, sockets, mutexes) devem estar encapsulados em classes com construtor e destrutor corretos.

// Ruim: raw pointer, gerenciamento manualvoid process() {    int* data = new int[100];    // ... esqueceu delete[] — vazamento}

// Bom: smart pointervoid process() {    auto data = std::make_unique<int[]>(100);    // a memória será liberada automaticamente}

2. Correção no uso da STL e algoritmos

A biblioteca padrão do C++ é poderosa, mas fácil de usar incorretamente.

• Verifique se não há um loop manual onde poderia ser usado std::find, std::copy, std::transform.
• Preste atenção à invalidação de iteradores (por exemplo, após push_back em std::vector).
• Se const está sendo usado para referências quando o objeto não é modificado (const std::string& em vez de std::string).

// Ruim: cópia da string e busca manualbool hasValue(std::string s, char c) {    for (size_t i = 0; i < s.size(); ++i) {        if (s[i] == c) return true;    }    return false;}

// Bom: const reference e algoritmobool hasValue(const std::string& s, char c) {    return std::find(s.begin(), s.end(), c) != s.end();}

3. Regras do C++ moderno (C++11/14/17/20)

Construções obsoletas são um sinal de alerta.

• Substituição de typedef por using.
• Uso de auto para tipos complexos (mas não em todo lugar — legibilidade é mais importante).
• Aplicação de nullptr em vez de NULL ou 0.
• Verificação de constexpr e noexcept onde apropriado.

4. Performance e arquitetura

Mesmo código correto pode ser lento ou difícil de manter.

• Evite cópias desnecessárias: passar objetos grandes por valor é um erro comum.
• Verifique se uma função virtual não está sendo chamada em um loop crítico (a menos que seja justificado).
• Avalie o acoplamento das classes: o código não viola os princípios SOLID?

Como dar feedback: regras para uma revisão construtiva

A parte técnica é metade do trabalho. A outra metade é o fator humano. Um comentário mal apresentado pode desmotivar o autor ou causar conflito.

1. Separe a crítica ao código da pessoa

Fale sobre o código, não sobre o programador. Em vez de "Você escreveu um código horrível", diga "Neste trecho, é melhor usar um smart pointer para evitar vazamento".

2. Use o "porquê"