Code Review em C#: o que verificar para que o código não adoeça

Code Review em C#: não apenas uma formalidade, mas a salvação da produção

Você já viu um código que funciona, mas que dá vontade de fechar os olhos? "Números mágicos", loops dentro de loops, async void e null onde não deveria estar. O code review em C# não é um procedimento burocrático, mas a última linha de defesa antes que um bug vá para produção. Ou, pior ainda, antes que seus colegas comecem a dar manutenção no código, amaldiçoando o autor.

Neste artigo, vamos analisar no que realmente prestar atenção ao revisar código C#. Nada de enrolação — apenas casos concretos, antipadrões e exemplos. Se você é júnior, este é seu checklist. Se é sênior, refresque a memória. Vamos nessa.

1. Null — o principal inimigo do desenvolvedor C#

O famoso NullReferenceException é a causa de milhões de noites sem dormir. A primeira coisa que verificamos em um code review: proteção contra null.

O que deve acender um alerta?

\n
• Ausência de verificação de null antes de acessar propriedades.
\n
• Retorno de null de métodos onde se espera uma coleção.
\n
• Ignorar contextos anuláveis (#nullable enable).
\n

Ruim:

public string GetUserName(User user)\n{\n    return user.Name.ToUpper(); // user pode ser null!\n}

Bom (C# 8+):

public string GetUserName(User? user)\n{\n    return user?.Name?.ToUpper() ?? "Unknown";\n}

Dica para code review: exija a ativação de Nullable em novos projetos. Não é apenas moda, isso evita erros bobos. Code review C# sem verificar nullable é como dirigir sem cinto de segurança.

2. Assincronicidade: async/await sem armadilhas

Programação assíncrona em C# é uma ferramenta poderosa, mas quando usada incorretamente, vira uma bomba-relógio. Na revisão, verificamos três pecados capitais.

Pecado nº1: async void

Métodos async void não podem ser rastreados — a exceção cai na thread final e mata o processo. Só é permitido para manipuladores de eventos (ex.: botões no WinForms).

Ruim:

public async void LoadDataAsync()\n{\n    var data = await _service.GetDataAsync(); // Erro mata o processo\n}

Bom:

public async Task LoadDataAsync()\n{\n    var data = await _service.GetDataAsync();\n}

Pecado nº2: Bloqueio de código assíncrono

.Result ou .Wait() em contexto assíncrono é caminho certo para deadlock.

Ruim:

var result = _service.GetDataAsync().Result; // deadlock em aplicações UI

Bom:

var result = await _service.GetDataAsync();

Pecado nº3: Ausência de CancellationToken

Operações longas devem ser canceláveis. Se na assinatura do método não há CancellationToken, pergunte ao autor: "O que acontece se o usuário fechar a aba?"

3. LINQ: beleza ou morte lenta?

LINQ é elegante. Mas o code review frequentemente revela que por trás da elegância se esconde O(n²) ou múltiplas iterações na coleção.

Erros típicos ao revisar código C# com LINQ:

\n
• Múltiplas iterações: .Count() > 0 + .First() — duas passagens. Use .Any() e .FirstOrDefault().
\n
• ToList() esquecido: carregamento preguiçoso pode fazer com que a consulta ao banco seja executada depois que o contexto DataReader já foi fechado.
\n
• Where + Select = redundância: se puder usar um único SelectMany, use.
\n

Exemplo que deve acender uma bandeira vermelha:

var result = l