Revisão de código em C#: 7 coisas que irritam desenvolvedores seniores

Introdução: Por que seu código irrita o sênior?

Você enviou um pull request. Cinco minutos se passaram. No chat chega: "E se reescrevêssemos este bloco?" e uma dezena de comentários em cada segunda linha. Familiar? Se você programa em C# e trabalha em equipe, code review não é apenas uma caixa de seleção no Jira. É o momento da verdade.

Reuni os comentários típicos que os seniores deixam na revisão de código C#. Não é sobre sintaxe — é sobre pensamento. Sobre como transformar "código que apenas funciona" em código que não dá vontade de reescrever na primeira sexta-feira.

Vamos analisar os antipadrões C# que irritam até os líderes de equipe mais calmos.

1. Números e strings mágicos: "O que isso significa?"

O comentário mais comum na revisão de código C# é a pergunta sobre números. Você escreve if (status == 3), e o sênior pergunta imediatamente: "O que é 3? É o status 'Em processamento' ou 'Excluído'?"

Ruim:

if (order.Status == 3 && days > 7)\n{\n    CancelOrder(order);\n}\n

Bom:

private const int OrderStatusCancelled = 3;\nprivate const int MaxDaysBeforeAutoCancel = 7;\n\nif (order.Status == OrderStatusCancelled && days > MaxDaysBeforeAutoCancel)\n{\n    CancelOrder(order);\n}\n

Ainda melhor — extrair para um enum. Seniores adoram código legível, onde não é preciso consultar o banco de dados para entender a lógica de negócio. Esta é uma regra básica de code review C#: o código deve falar por si só.

2. Async void — a assassina silenciosa de aplicações

Se você escreve async void em qualquer lugar que não sejam manipuladores de eventos (por exemplo, em WPF ou WinForms), prepare-se para um grande ponto negativo. Async void não pode ser rastreado — a exceção cai no vazio e derruba o processo.

Ruim:

public async void LoadData()\n{\n    var data = await _repository.GetDataAsync();\n    // Se falhar aqui — a aplicação cai sem mensagem de erro\n}\n

Bom:

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

Na revisão de código C#, o sênior certamente apontará isso. Lembre-se: async Task é seu amigo, async void é inimigo (exceto em eventos).

3. Classes Godzilla: Princípio da Responsabilidade Única

Você abre um arquivo e lá estão 2000 linhas. Uma única classe faz tudo: acessa o banco, envia e-mail, gera relatório e ainda faz café. Este é o clássico antipadrão C# — God Object.

O sênior no code review C# dirá: "Vamos dividir em várias classes." E ele estará certo.

Exemplo de violação:

public class OrderService\n{\n    public void ProcessOrder(Order order)\n    {\n        // 1. Validação\n        // 2. Salvar no BD\n        // 3. Enviar e-mail\n        // 4. Log\n    }\n}\n

Como deveria ser:

public class OrderProcessor\n{\n    private readonly IOrderValidator _validator;\n    private readonly IOrderRepository _repository;\n    private readonly INotificationService _notificationService;\n\n    public OrderProcessor(\n        IOrderValidator validator,\n        IOrderRepository repository,\n        INotificationService notificationService)\n    {\n        _validator = validator;\n        _repository = repository;\n        _notificationService = notificationService;\n    }\n\n    public async Task ProcessOrderAsync(Order order)\n    {\n        _validator.Validate(order);\n        await _repository.SaveAsync(order);\n        await _notificationService.SendConfirmationAsync(order);\n    }\n}\n

Isso não é apenas "bonito". É testável. Você pode mockar o repositório e verificar apenas a lógica de processamento. Refatoração C# nesse estilo é must-have para qualquer projeto.

4. Exceções como estruturas de controle