Código limpio en C#: cómo escribir para que no te dé vergüenza mostrarlo a tus colegas

Introducción: por qué el código limpio no es cuestión de estética, sino de dinero

Imagina que llegas a un nuevo trabajo, abres un proyecto en C# y ves un método de 500 líneas, variables a, b, temp, y comentarios escritos en una mezcla de ruso e inglés. ¿Te suena? Probablemente sí. Ese código funciona, pero su mantenimiento se convierte en un infierno. El código limpio en C# no es un capricho de perfeccionista, sino una herramienta que ahorra horas, nervios y dinero al equipo.

En este artículo no daremos sermones. En su lugar, analizaremos técnicas concretas que te ayudarán a escribir en C# de forma que el código sea comprensible para un principiante y agrade para un desarrollador experimentado. ¡Allá vamos!

1. Los nombres importan: cómo nombrar variables, métodos y clases

La forma más sencilla de hacer el código más limpio es dar nombres con significado. C# es estricto con las mayúsculas y minúsculas, pero eso no es excusa para int x o string d.

Variables: di lo que almacenas

Mal:

int d; // ¿qué es esto? ¿fecha? ¿distancia? ¿dinero?string n; // ¿nombre? ¿número? ¿ordenador portátil?

Bien:

int daysUntilDeadline;string userName;

La regla es simple: si dentro de un mes no puedes entender qué almacena una variable sin un comentario, el nombre es malo. Evita abreviaturas como usr o cnt: ahorran un segundo al escribir, pero restan minutos al leer.

Métodos: verbo + sustantivo

Un método es una acción. Nómbralo de forma que quede claro lo que hace:

• CalculateTotalPrice() — calcula el precio total;
• SendEmailNotification() — envía una notificación;
• ValidateUserInput() — valida la entrada del usuario.

Ejemplo malo: ProcessData() — demasiado abstracto. ¿Qué significa "procesar"? ¿Eliminar? ¿Transformar? ¿Guardar?

Clases: sustantivos en singular o plural

Una clase es una entidad. User, Order, PaymentProcessor. Evita sufijos como Manager o Helper a menos que la arquitectura lo justifique. A menudo, estas clases se convierten en un "vertedero" para todo tipo de cosas.

2. Los métodos deben ser pequeños y hacer una sola cosa

La regla de oro del código limpio: un método debe resolver una tarea y hacerla bien. Si un método ocupa más de 20–30 líneas, probablemente deba dividirse.

Ejemplo: refactorización de un monstruo

Imagina un método que registra un usuario:

public void RegisterUser(string name, string email){    // validación    if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException();    if (!email.Contains("@")) throw new ArgumentException();    // guardar en BD    using var db = new AppDbContext();    var user = new User { Name = name, Email = email };    db.Users.Add(user);    db.SaveChanges();    // enviar correo    var smtp = new SmtpClient();    smtp.Send("admin@site.com", email, "Welcome", "Hello!");}

¿Qué hay de malo aquí? Tres responsabilidades: validación, trabajo con BD, envío de correo. Si cambia la lógica de envío, habrá que modificar el método de registro. Dividamos:

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