Revisão de código em C++: no que os seniors pegam primeiro

Introdução: por que sua revisão está se transformando em um campo de batalha?

Você enviou um Merge Request. Parece tudo limpo, a lógica correta, o código compila. Uma hora depois, chega a resposta do senior: "-10 pontos para a Grifinória" e 35 comentários em 200 linhas de código. Familiar?

A revisão de código em C++ não é apenas uma verificação de sintaxe. É uma arte que separa juniors de seniors. C++ dá ao desenvolvedor um enorme poder sobre a memória e o desempenho, mas com grandes poderes vêm grandes responsabilidades por comportamento indefinido e vazamentos de recursos.

Neste artigo, vamos entrar na mente de um revisor experiente. Reuni comentários reais que seniors deixam em code reviews em projetos de produção. Se você programa em C++ e quer que seus PRs sejam aprovados na primeira tentativa — leia com atenção. E se você é tech lead — use esta checklist para integrar novatos.

1. Tiro no pé: gerenciamento manual de memória

A polêmica mais comum em revisões é "por que você não está usando ponteiros inteligentes?". Seniors odeiam new e delete puros em C++ moderno (C++11 e posteriores).

Exemplo ruim

class DataProcessor {\n    int* buffer;\n    size_t size;\npublic:\n    DataProcessor(size_t s) : size(s) {\n        buffer = new int[s]; // Quem vai deletar?\n    }\n\n    ~DataProcessor() {\n        delete[] buffer; // E se houver uma exceção no construtor?\n    }\n};

Comentário do senior: "Violação de RAII. Se o construtor lançar uma exceção após a alocação de memória — o destrutor não será chamado. Vazamento de memória. Use std::vector ou std::unique_ptr."

Exemplo correto

class DataProcessor {\n    std::vector<int> buffer;\npublic:\n    explicit DataProcessor(size_t s) : buffer(s) {}\n};

Seniors adoram RAII (Resource Acquisition Is Initialization). Se você escreve new no código, esteja preparado para explicar por que std::make_unique ou std::vector não são adequados. Em 95% dos casos, eles são.

2. Const-correctness: coloque sua "vírgula"

Um const faltando é uma bandeira vermelha para qualquer desenvolvedor senior em C++. Não é apenas estilo, é um contrato com o leitor do código e com o compilador.

O que irrita na revisão

std::string getName() { // Por que não const?\n    return name;\n}\n\nvoid printData(std::vector<int>& data) { // Cópia? Referência? Modifica?\n    for (auto& item : data) {\n        std::cout << item;\n    }\n}

Comentário do senior: "O método getName() não modifica o objeto — torne-o const. O parâmetro data não é modificado — passe const std::vector<int>&. Caso contrário, o código chamador não sabe se você vai modificar os dados dele ou não."

Corrigindo

std::string getName() const { // método const\n    return name;\n}\n\nvoid printData(const std::vector<int>& data) { // referência const\n    for (const auto& item : data) {\n        std::cout << item;\n    }\n}

A regra é simples: se o método não altera o estado do objeto — const. Se a função não altera o argumento — const T&. Const correctness em C++ não é uma opção, é um padrão.

3. Move semantics: copiar não é a nossa religião

C++ moderno é sobre mover, não copiar. Seniors percebem imediatamente onde você cria cópias desnecessárias e prejudica o desempenho.

Padrão ruim

std::vector<int> processData(std::vector<int> data) { // Cópia na entrada\n    // ... muita lógica ...\n    return data; // Cópia na saída? Ou NRVO?\n}\n\nvoid caller() {\n    std::vector<int> bigData = {1, 2, 3, ... 1000000};\n    auto result = processData(bigData); // Mais uma cópia!\n}

Coment