Regla
Elimine obvio dentro del archivo dentro de un archivo.
Duplicado código bloques aumentan mantenimiento
mantenimiento y el riesgo de inconsistentes inconsistentes.
Idiomas compatibles: 45+

Introducción

El código copiado y pegado dentro de un único archivo genera pesadillas de mantenimiento que se agravan con el tiempo. Cuando la misma lógica aparece en varios lugares, las correcciones de errores y las actualizaciones de características deben aplicarse a cada una de las ocurrencias. Los desarrolladores inevitablemente omiten uno de los duplicados, lo que lleva a un comportamiento inconsistente donde la misma operación produce resultados diferentes según la ruta de código que se ejecute. Esta inconsistencia es difícil de depurar porque la lógica duplicada parece idéntica a primera vista, y las diferencias solo emergen después de una comparación cuidadosa.

Por qué es importante

Propagación de errores: Cuando un error existe en código duplicado, corregirlo en una ubicación no lo corrige en todas partes. Los desarrolladores corrigen la primera ocurrencia sin darse cuenta de que existen copias en otros lugares, dejando el error activo bajo diferentes condiciones.

Carga de mantenimiento: Cada bloque duplicado duplica el coste de mantenimiento. Cambiar la lógica requiere encontrar y actualizar cada copia, y a medida que los archivos crecen, el seguimiento de los duplicados se vuelve más difícil.

Ejemplos de código

❌ No conforme:

class OrderProcessor {
    async processStandardOrder(order) {
        if (!order.items || order.items.length === 0) {
            throw new Error('Order must have items');
        }
        const total = order.items.reduce((sum, item) => 
            sum + (item.price * item.quantity), 0);
        const tax = total * 0.08;
        const finalAmount = total + tax;
        return { total: finalAmount, tax };
    }
    
    async processExpressOrder(order) {
        if (!order.items || order.items.length === 0) {
            throw new Error('Order must have items');
        }
        const total = order.items.reduce((sum, item) => 
            sum + (item.price * item.quantity), 0);
        const tax = total * 0.08;
        const expressfee = 15.99;
        const finalAmount = total + tax + expressFee;
        return { total: finalAmount, tax, expressFee };
    }
}

Por qué está mal: La lógica de validación y el cálculo total están duplicados. Si la tasa de impuestos cambia o la validación necesita mejoras, ambos métodos requieren actualizaciones. Un desarrollador podría actualizar el cálculo de impuestos en un método pero olvidarse del otro, causando precios inconsistentes.

✅ Conforme:

class OrderProcessor {
    validateOrder(order) {
        if (!order.items || order.items.length === 0) {
            throw new Error('Order must have items');
        }
    }
    
    calculateSubtotal(items) {
        return items.reduce((sum, item) => 
            sum + (item.price * item.quantity), 0);
    }
    
    calculateTax(amount) {
        return amount * 0.08;
    }
    
    async processStandardOrder(order) {
        this.validateOrder(order);
        const subtotal = this.calculateSubtotal(order.items);
        const tax = this.calculateTax(subtotal);
        return { total: subtotal + tax, tax };
    }
    
    async processExpressOrder(order) {
        this.validateOrder(order);
        const subtotal = this.calculateSubtotal(order.items);
        const tax = this.calculateTax(subtotal);
        const expressFee = 15.99;
        return { total: subtotal + tax + expressFee, tax, expressFee };
    }
}

Por qué es importante: La lógica de validación, cálculo e impuestos está centralizada en métodos únicos. Cambiar el tipo impositivo significa modificar un solo método, no buscar duplicados en el archivo. Cada método auxiliar puede probarse de forma independiente, y ambos tipos de pedido heredan automáticamente cualquier mejora o corrección de errores.

Conclusión

La duplicación dentro de un archivo suele ser la más fácil de corregir y proporciona beneficios inmediatos. Extrae la lógica duplicada en funciones o métodos auxiliares tan pronto como detectes el patrón. La regla de tres sugiere que una vez que el código aparece tres veces, es hora de refactorizar. No esperes a que la duplicación se extienda por todo el archivo antes de abordarla.