Código limpo em C#: como escrever para não ter vergonha de mostrar aos colegas

Introdução: por que código limpo não é sobre estética, mas sobre dinheiro

Imagine que você chega em um novo emprego, abre um projeto em C# e vê um método de 500 linhas, variáveis a, b, temp, e comentários escritos em uma mistura de português e inglês. Familiar? Provavelmente sim. Esse código funciona, mas sua manutenção se torna um inferno. Código limpo em C# não é um capricho de perfeccionista, mas uma ferramenta que economiza horas, nervos e dinheiro da equipe.

Neste artigo, não vamos dar lições de moral. Em vez disso, vamos analisar técnicas específicas que ajudarão você a escrever em C# de forma que o código seja compreensível para um iniciante e agrade um desenvolvedor experiente. Vamos lá!

1. Nomes importam: como nomear variáveis, métodos e classes

A maneira mais simples de tornar o código mais limpo é dar nomes significativos. C# é sensível a maiúsculas e minúsculas, mas isso não é desculpa para int x ou string d.

Variáveis: diga o que você armazena

Ruim:

int d; // o que é isso? data? distância? dinheiro?string n; // nome? número? notebook?

Bom:

int daysUntilDeadline;string userName;

A regra é simples: se em um mês você não conseguir entender o que a variável armazena sem um comentário — o nome é ruim. Evite abreviações como usr ou cnt — elas economizam um segundo na digitação, mas custam minutos na leitura.

Métodos: verbo + substantivo

Um método é uma ação. Nomeie-o de forma que fique claro o que ele faz:

• CalculateTotalPrice() — calcula o preço total;
• SendEmailNotification() — envia uma notificação;
• ValidateUserInput() — valida a entrada do usuário.

Exemplo ruim: ProcessData() — muito abstrato. O que significa "processar"? Excluir? Transformar? Salvar?

Classes: substantivos no plural ou singular

Uma classe é uma entidade. User, Order, PaymentProcessor. Evite sufixos como Manager ou Helper, a menos que seja justificado pela arquitetura. Frequentemente, essas classes se tornam um "depósito" para tudo.

2. Métodos devem ser pequenos e fazer uma única coisa

A regra de ouro do código limpo: um método deve resolver uma única tarefa e resolvê-la bem. Se um método tiver mais de 20–30 linhas — provavelmente, ele precisa ser dividido.

Exemplo: refatoração de um monstro

Imagine um método que registra um usuário:

public void RegisterUser(string name, string email){    // validação    if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException();    if (!email.Contains("@")) throw new ArgumentException();    // salvamento no BD    using var db = new AppDbContext();    var user = new User { Name = name, Email = email };    db.Users.Add(user);    db.SaveChanges();    // envio de e-mail    var smtp = new SmtpClient();    smtp.Send("admin@site.com", email, "Welcome", "Hello!");}

O que há de errado aqui? Três responsabilidades: validação, trabalho com BD, envio de e-mail. Se a lógica de envio mudar, você terá que mexer no método de registro. Vamos dividir:

public void RegisterUser(string name, string email){    ValidateUser(name, email);    var user = CreateUser(name, email);    SaveUser(user);    SendWelcomeEmail(email);}

private void ValidateUser(string name, string email){    if (string.IsNullOrWhiteSpace(name))         throw new ArgumentException("Name is required", nameof(name));    if (!email.Contains("@"))         throw new ArgumentException("Invalid email", nameof(email));}

private User CreateUser(string name, string email){    return new User { Name = name, Email = email };}

private void SaveUser(User user){    using var db = new AppDbContext();    db.Users.Add(user);    db.SaveCh