Clean Code en C#: principios y ejemplos para desarrolladores .NET

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Clean Code en C#: principios y ejemplos prácticos

El código limpio (Clean Code) no es solo un término de moda, sino una habilidad fundamental para el desarrollador profesional. En el ecosistema .NET y C#, donde los proyectos a menudo viven durante años y son mantenidos por decenas de programadores, la capacidad de escribir código comprensible y fácilmente modificable se vuelve críticamente importante. En este artículo analizaremos los principios principales de Clean Code aplicados a C# y veremos ejemplos concretos de su aplicación.

¿Por qué es importante el código limpio en C#?

C# es un lenguaje fuertemente tipado, orientado a objetos y con un rico ecosistema. Sin embargo, su poder puede convertirse en caos si no se sigue una disciplina. El código limpio reduce la cantidad de errores, acelera la incorporación de nuevos desarrolladores y disminuye el costo de mantenimiento. Como decía Robert Martin: «La única forma de escribir código rápido es escribirlo bien».

Principio 1: Nombres que hablan

Los nombres de variables, métodos y clases deben revelar la intención. No ahorre caracteres: el código malo requiere más tiempo para ser comprendido.

Ejemplo malo

int d; // tiempo desde el cambioList<int> lst = new List<int>();void Proc(int a, int b) { ... }

Ejemplo bueno (Clean Code)

int elapsedTimeInDays;List<int> customerIds = new List<int>();void CalculateDiscount(decimal basePrice, decimal taxRate) { ... }

Regla: Si un nombre necesita un comentario, es malo. Use camelCase para variables y PascalCase para métodos y clases.

Principio 2: Funciones pequeñas (SRP a nivel de métodos)

Cada función debe hacer exactamente una cosa y hacerla bien. Si un método contiene más de 20-30 líneas o tiene más de dos niveles de anidamiento, es una señal para refactorizar.

Ejemplo malo: función navaja suiza

public void ProcessOrder(Order order){    // Validación    if (order == null || order.Items.Count == 0)        throw new ArgumentException("Invalid order");

    // Cálculo de descuento    decimal discount = 0;    if (order.Total > 1000) discount = 0.1m;    else if (order.Total > 500) discount = 0.05m;

    // Guardar en BD    using var db = new AppDbContext();    db.Orders.Add(order);    db.SaveChanges();

    // Enviar email    SendEmail(order.CustomerEmail, "Order received");}

Ejemplo bueno: separación de responsabilidades

public void ProcessOrder(Order order){    Validate(order);    var discount = CalculateDiscount(order.Total);    ApplyDiscount(order, discount);    SaveOrder(order);    SendConfirmationEmail(order);}

private void Validate(Order order){    if (order == null || order.Items.Count == 0)        throw new ArgumentException("Invalid order");}

private decimal CalculateDiscount(decimal total){    if (total > 1000) return 0.1m;    if (total > 500) return 0.05m;    return 0;}

private void SaveOrder(Order order){    using var db = new AppDbContext();    db.Orders.Add(order);    db.SaveChanges();}

Principio 3: Evite la duplicación (DRY)

El código repetido es la raíz de todos los males. Si copia un bloque de código más de una vez, extráigalo a un método o clase.

Ejemplo: lógica duplicada

// En el controlador de usuariosif (user.Role == "Admin" || user.Role == "Manager")    GrantAccess();

// En el controlador de reportesif (user.Role == "Admin" || user.Role == "Manager")    ShowReport();

Refactorización: encapsulación de la verificación

public static class UserExtensions{    public static bool HasElevatedPermissions(this User user)    {        return user.Role == "Admin" || user.Role == "Manager";    }}

// Usoif (user.HasElevatedPermissions())    GrantAccess();