Código basura en programación: qué es, señales y cómo escribir más limpio

Qué es el código basura en programación

El código basura es una caracterización subjetiva pero generalmente aceptada del código que no cumple con los estándares mínimos de calidad. Robert Martin en su libro Código limpio (2008) define el código deficiente como aquel que “impide entender lo que hace”. El código basura puede ser sintácticamente correcto e incluso funcionar, pero su mantenimiento se convierte en una pesadilla para el equipo.

El término govnokod está muy extendido precisamente en la comunidad de habla rusa. En inglés se usan términos más formales: spaghetti code, dirty code, technical debt code. Sin embargo, la carga emocional de “código basura” transmite con mayor precisión la actitud de los desarrolladores hacia dicho código: una mezcla de irritación, disgusto y ofensa profesional.

Según un estudio de McKinsey (2023), las empresas con altos niveles de deuda técnica — y el código basura es su componente principal — gastan entre un 20% y un 40% más recursos en desarrollar nuevas funcionalidades. La calidad del código afecta directamente a las métricas de negocio, y esto no es una metáfora sino un hecho confirmado.

El límite entre el código basura y el código normal

No existen métricas objetivas, pero hay criterios prácticos: si un desarrollador tarda más de 5 minutos en entender una función de 20 lín­as — es código basura. Si cambiar una línª rompe tres módulos no relacionados — es código basura. Si el código no se puede cubrir con pruebas sin una reescritura completa — es código basura.

Señales principales de código basura

La copia y pega (copy-paste programming) es una de las señales más evidentes y fáciles de detectar. Cuando el mismo bloque de código se repite en varios lugares con cambios mínimos, no es solo código basura — es una fuente de futuros errores. Corregirlo en un lugar y omitirlo en otro es una situación típica.

Los nombres de variables sin significado son un clásico. Variables con nombres como `a`, `b`, `x`, `data`, `temp`, `tmp`, `result`, `list`, `obj` no aportan ninguna información sobre su propósito. El lector del código tiene que analizar toda la función para entender qué contiene la variable. Robert Martin llama a esto “una mentira en el nombre” — el nombre promete información pero no la entrega.

El anidamiento profundo — cuando condiciones, bucles y manejo de errores crean una estructura con 5+ niveles de sangría. Ese código es imposible de leer sin desplazamiento horizontal o seguimiento mental de todos los niveles. Esto es un camino directo a los errores: los operadores lógicos se confunden fácilmente y los corchetes de cierre se pasan por alto.

Señales ocultas

Código muerto (dead code) — funciones, variables, clases que no se usan en ningún lugar. Esto aumenta el volumen de código, distrae al desarrollador y crea una falsa impresión de las capacidades del sistema. Números mágicos — números sin contexto. Clases Dios (God classes) — clases que hacen todo a la vez, violando el principio de responsabilidad única (SOLID: S).

Por qué aparece el código basura

La falta de tiempo es la razón más común. Cuando los plazos apremian, los desarrolladores sacrifican la calidad por la velocidad. Tácticamente esto puede estar justificado, pero estratégicamente — es acumulación de deuda técnica. El problema es que el código basura “temporal” rara vez se retoma para corregirlo.

La falta de revisión de código es la segunda razón más importante. Cuando el código se escribe en solitario sin revisión de colegas, los malos patrones se arraigan y se multiplican. La revisión de código no es solo control de calidad, sino también transferencia de conocimiento dentro del equipo. Los proyectos sin revisión inevitablemente degeneran en código basura.

La baja cualificación del desarrollador o la falta de mentoría. Los desarrolladores junior que trabajan sin supervisión escriben código basura de forma natural — es parte del proceso de aprendizaje. El problema surge cuando este código llega a producción sin revisión ni refactorización.

Factores culturales

En los equipos donde “funciona y ya está” es el lema, el código basura prospera. La ausencia de estándares de codificación, requisitos de prueba y procesos de revisión crea un entorno donde la calidad del código no le importa a nadie. Estos proyectos se vuelven rápidamente “legacy” — código que todos temen tocar.

Consecuencias del código basura para el proyecto

La principal consecuencia del código basura es la ralentización del desarrollo. La paradoja del código deficiente es que permite escribir rápidamente la primera versión, pero cada corrección posterior requiere cada vez más tiempo. La gráfica de velocidad de desarrollo frente a calidad del código es exponencial — después de cierto umbral, añadir nuevas funcionalidades se vuelve prácticamente imposible.

La rotación de personal es una consecuencia indirecta pero grave. Los desarrolladores, especialmente los experimentados, no quieren trabajar con código basura. Según la Encuesta a Desarrolladores de Stack Overflow 2024, el 47% de los desarrolladores considera la calidad de la base de código como uno de los factores clave al elegir un lugar de trabajo. Los proyectos con código deficiente pierden a sus mejores empleados.

La seguridad es otra víctima del código basura. El código mal escrito contiene más vulnerabilidades: excepciones no controladas, inyecciones SQL, XSS, fugas de memoria. El código de calidad con pruebas unitarias y revisión de código detecta la mayoría de estos problemas antes de llegar a producción.

La deuda técnica como métrica

SonarQube y herramientas similares pueden estimar la deuda técnica en horas-hombre o días. Por ejemplo, 500 advertencias de copia y pega, 200 de números mágicos y 50 de anidamiento profundo dan una estimación de 30 días de deuda técnica. Estas cifras se pueden y deben mostrar a la dirección para justificar la refactorización.

Cómo escribir código limpio en lugar de código basura

El principio DRY (Don’t Repeat Yourself) es lo primero que hay que implementar. Cada fragmento de lógica debe existir en un único lugar. En lugar de copiar y pegar — extrae el código repetido en una función, clase o módulo separados. En lugar de números mágicos — constantes con nombre. En lugar de funciones largas — varias pequeñas.

El principio KISS (Keep It Simple, Stupid) protege contra la complejidad excesiva. Si una tarea se puede resolver en 10 lín­as — no escribas 50. Si un bucle es más simple que un stream — usa un bucle. Si una función normal es más clara que un decorador — escribe una función. La simplicidad es la principal cualidad del código mantenible.

La regla Boy Scout — “deja el código mejor de lo que lo encontraste”. Incluso pequeñas mejoras en cada edición convierten gradualmente el código basura en código decente. Renombrar una variable, dividir una función grande, añadir una prueba — cualquier mejora cuenta.

// código basura — copia y pega, números mágicos, nombres pobres
function calc(a, b, c) {
  let x = a * 0.85;
  if (b > 1000) { x = x * 0.9; }
  let y = c * 0.85;
  if (b > 1000) { y = y * 0.9; }
  return x + y;
}

// código limpio — nombres claros, DRY, constantes
const DISCOUNT_RATE = 0.85;
const BULK_THRESHOLD = 1000;
const BULK_DISCOUNT = 0.9;

function applyDiscount(amount, quantity) {
  let price = amount * DISCOUNT_RATE;
  if (quantity > BULK_THRESHOLD) {
    price = price * BULK_DISCOUNT;
  }
  return price;
}

function calculateTotal(items, quantity) {
  return items.reduce((sum, item) => {
    return sum + applyDiscount(item, quantity);
  }, 0);
}

Ejemplos de refactorización

Consideremos un ejemplo típico en Python. La función procesa pedidos pero lo hace mal: 80 lín­as, anidamiento profundo, números mágicos, duplicación. Después de la refactorización, el código se vuelve legible, comprobable y mantenible.

# código basura — una sola función lo hace todo
def process_order(order):
    if order.get("type") == "premium":
        if order["amount"] > 100:
            discount = 0.8
        else:
            discount = 0.9
    else:
        discount = 1.0
    total = order["amount"] * discount
    return total

# código limpio — funciones y constantes extraídas
class OrderProcessor:
    PREMIUM_DISCOUNT_HIGH = 0.8
    PREMIUM_DISCOUNT_LOW = 0.9
    PREMIUM_THRESHOLD = 100

    def get_discount(self, order):
        if order.type == "premium" and order.amount > self.PREMIUM_THRESHOLD:
            return self.PREMIUM_DISCOUNT_HIGH
        return self.PREMIUM_DISCOUNT_LOW

    def calculate_total(self, order):
        return order.amount * self.get_discount(order)

La regla de las tres lín­as para funciones

Una buena función hace una cosa y la hace bien. Si una función hace tres cosas diferentes — divídelas. Si una función tiene más de 20 lín­as — probablemente se pueda dividir. Si una función tiene más de dos niveles de sangría — necesita refactorización.

Herramientas de revisión de código

Los analizadores estáticos de código son la primera línª de defensa contra el código basura. ESLint (JavaScript), Pylint (Python), SonarQube (multilenguaje), Checkstyle (Java) detectan automáticamente copias y pegas, números mágicos, bloques catch vacíos, funciones demasiado largas y cientos de otros antipatrones.

Los formateadores y estándares de código (code style) son el segundo nivel de protección. Prettier, Black, gofmt formatean el código automáticamente, eliminando problemas con espacios, sangrías y corchetes. Un estilo coherente en todo el equipo hace que el código sea legible independientemente de quién lo haya escrito. Las discusiones sobre formato deben automatizarse.

La revisión de código es el tercer nivel y el más importante. Ningún analizador puede reemplazar a una persona que note que la arquitectura de la solución es incorrecta o que el desarrollador eligió el enfoque equivocado. Una revisión eficaz requiere tiempo, pero se amortiza reduciendo significativamente la cantidad de código basura.

• ESLint — para JavaScript y TypeScript con reglas de complejidad, max-lines, max-nested-callbacks
• Pylint — para Python con métricas de código y puntuación de calidad (de -10 a 10)
• SonarQube — para realizar un seguimiento de la deuda técnica a lo largo del tiempo
• CodeClimate — para evaluar el índice de mantenibilidad de cada archivo
• Better Code Hub — para verificar el cumplimiento de los 10 principios del código limpio