Code review em C#: o que verificar e como dar feedback para iniciantes

Code review em C#: por onde começar e o que procurar

Code review (revisão de código) não é apenas uma formalidade, mas uma ferramenta poderosa para melhorar a qualidade do projeto e o crescimento da equipe. Para desenvolvedores iniciantes em C#, o processo de revisar o código de outra pessoa muitas vezes causa medo: "E se eu deixar passar um bug?", "Como dizer ao colega que o código dele está ruim?". Neste artigo, vamos analisar o que observar durante o code review em projetos .NET e como dar feedback de forma que você seja ouvido, e não ofenda.

Não falaremos sobre coisas óbvias como erros de sintaxe — o compilador os detecta. Nosso objetivo é aprender a enxergar problemas de arquitetura, legibilidade e desempenho, além de formular observações corretamente.

1. Arquitetura e princípios SOLID em C#

A primeira coisa a verificar no código C# é se ele segue os princípios SOLID. Mesmo em um método pequeno, é possível perceber a violação do princípio da responsabilidade única (Single Responsibility).

O que verificar:

• Tamanho dos métodos e classes. Se um método tem mais de 20-30 linhas, provavelmente está fazendo demais. Sugira dividi-lo em vários métodos privados.
• Inversão de dependências. As classes não devem criar suas dependências usando new. Em vez disso, use injeção de dependência (DI). Exemplo de código ruim:

// Ruim: a classe cria a dependência sozinhapublic class OrderService{    private readonly EmailSender _sender = new EmailSender();

    public void ProcessOrder(Order order)    {        // lógica...        _sender.SendEmail(order.CustomerEmail);    }}

A versão correta — através de interface e DI:

// Bom: a dependência é injetadapublic class OrderService{    private readonly IEmailSender _sender;

    public OrderService(IEmailSender sender)    {        _sender = sender;    }

    public void ProcessOrder(Order order)    {        // lógica...        _sender.SendEmail(order.CustomerEmail);    }}

• Princípio da substituição de Liskov (LSP). As subclasses não devem quebrar o comportamento da classe base. Por exemplo, se você tem uma classe Bird com um método Fly() e cria Penguin : Bird — isso viola o LSP, pois pinguins não voam. É melhor criar uma interface IFlyable.

2. Tratamento de erros e exceções em .NET

Em C#, existe um sistema de exceções poderoso, mas iniciantes costumam usá-lo incorretamente. Durante o code review, preste atenção aos seguintes pontos:

• Blocos catch vazios. Código como catch (Exception) { } é uma bomba-relógio. O erro é engolido e você nunca saberá do problema. Sempre registre a exceção ou a propague adiante.
• Exceções muito genéricas. Capturar Exception é uma má prática. Tente capturar tipos específicos: SqlException, InvalidOperationException, etc.
• Uso de exceções para controle de fluxo. Não use try-catch no lugar de if-else. Exemplo de código ruim:

// Ruim: exceção como parte da lógicatry{    int.Parse(userInput);}catch (FormatException){    Console.WriteLine("Formato inválido");}

A versão correta — int.TryParse():

// Bom: verificação sem exceçãoif (int.TryParse(userInput, out int result)){    // trabalha com result}else{    Console.WriteLine("Formato inválido");}

3. Desempenho e gerenciamento de memória

Para desenvolvedores iniciantes em C#, o tópico de desempenho muitas vezes fica em segundo plano. No entanto, o code review é um ótimo momento para apontar construções ineficientes.

Problemas típicos:

• Excessivas