---
title: "Código espagueti"
type: "antipattern"
slug: "spaghetti-code"
url: "http://localhost:3000/es/antipatterns/spaghetti-code.md"
description: "Código fuente de software con una estructura deficiente"
---
# Código espagueti

> Código fuente de software con una estructura deficiente

El **código espagueti** es [código fuente](https://en.wikipedia.org/wiki/Source%5Fcode "Source code") [de computadora](https://en.wikipedia.org/wiki/Computer "Computer") que codifica un [flujo de control](https://en.wikipedia.org/wiki/Control%5Fflow "Control flow") tan enrevesado que resulta difícil de entender. Las instrucciones de control dirigen la [ejecución](https://en.wikipedia.org/wiki/Execution%5F%28computing%29 "Execution (computing)") del [programa](https://en.wikipedia.org/wiki/Computer%5Fprogram "Computer program") de maneras que, en lugar de poseer una estructura de calidad, se asemejan a los [espaguetis](https://en.wikipedia.org/wiki/Spaghetti "Spaghetti") cocidos, retorcidos y enredados. El código tiende a ser difícil de [mantener](https://en.wikipedia.org/wiki/Software%5Fmaintenance "Software maintenance").

Dado que la lógica de flujo de control codificada mediante la instrucción [goto](https://en.wikipedia.org/wiki/Goto "Goto") tiende a producir un flujo de control enrevesado, el uso de goto suele asociarse con la clasificación de código espagueti. La práctica de la [programación estructurada](https://en.wikipedia.org/wiki/Structured%5Fprogramming "Structured programming") se concibió para eliminar la necesidad y el uso de la instrucción goto como una forma de evitar la producción de código espagueti. Garantizar la creación de [software](https://en.wikipedia.org/wiki/Software "Software") de alta calidad, en lugar de código espagueti, suele implicar aspectos como el uso de mejores [herramientas](https://en.wikipedia.org/wiki/Software%5Ftool "Software tool"), la [formación](https://en.wikipedia.org/wiki/Training "Training") de los desarrolladores y la mejora de los [procesos de desarrollo de software](https://en.wikipedia.org/wiki/Software%5Fdevelopment%5Fprocess "Software development process").

El código espagueti también puede describir un [antipatrón](https://en.wikipedia.org/wiki/Anti-pattern "Anti-pattern") en el que el [código orientado a objetos](https://en.wikipedia.org/wiki/Object-oriented%5Fprogramming "Object-oriented programming") se escribe con un estilo procedimental, por ejemplo creando clases cuyos métodos son excesivamente largos y desordenados, o renunciando a conceptos de la orientación a objetos como el [polimorfismo](https://en.wikipedia.org/wiki/Polymorphism%5F%28computer%5Fscience%29 "Polymorphism (computer science)"). La presencia de esta forma de código espagueti puede reducir significativamente la comprensibilidad de un sistema.

## Historia

No está claro cuándo se acuñó la expresión _código espagueti_. Martin Hopkins hizo una referencia temprana a los espaguetis en este contexto en 1972, al escribir que la "principal motivación para eliminar la instrucción goto es la esperanza de que los programas resultantes no parezcan un plato de espaguetis". En el libro de 1978 _A primer on disciplined programming using PL/I, PL/CS, and PL/CT_, [Richard Conway](https://en.wikipedia.org/wiki/Richard%5FW.%5FConway "Richard W. Conway") describió programas que "tienen la misma estructura lógica limpia que un plato de espaguetis", una frase que se repitió en el libro de 1979 _An Introduction to Programming_, del que fue coautor junto a [David Gries](https://en.wikipedia.org/wiki/David%5FGries "David Gries"). En el artículo de 1988 _A spiral model of software development and enhancement_, el término se utiliza para describir la antigua práctica del _modelo de codificar y corregir_, que carecía de planificación y que con el tiempo condujo al desarrollo del [modelo en cascada](https://en.wikipedia.org/wiki/Waterfall%5Fmodel "Waterfall model"). En el libro de 1979 _Structured programming for the COBOL programmer_, el autor Paul Noll utiliza las expresiones _código espagueti_ y _nido de ratas_ como sinónimos para describir código fuente mal estructurado.

En la conferencia _Ada – Europe '93_, se describió [Ada](https://en.wikipedia.org/wiki/Ada%5F%28programming%5Flanguage%29 "Ada (programming language)") como un lenguaje que obliga al programador a "producir código comprensible, en lugar de código espagueti", debido a su restrictivo mecanismo de propagación de excepciones.

En una publicación de 1980 de la [Oficina Nacional de Normas de los Estados Unidos](https://en.wikipedia.org/wiki/National%5FInstitute%5Fof%5FStandards%5Fand%5FTechnology "National Institute of Standards and Technology"), se utilizó la expresión _programa espagueti_ para describir programas antiguos que tenían "archivos fragmentados y dispersos".

En una parodia sobre lenguajes de programación publicada en 1981 en _The Michigan Technic_ y titulada "BASICally speaking...FORTRAN bytes!!", el autor describió [FORTRAN](https://en.wikipedia.org/wiki/FORTRAN "FORTRAN") afirmando que "consiste enteramente en código espagueti".

[Richard Hamming](https://en.wikipedia.org/wiki/Richard%5FHamming "Richard Hamming") describió en sus conferencias la etimología del término en el contexto de la programación temprana en códigos binarios:

> Si, al corregir un error, querías insertar algunas instrucciones omitidas, tomabas la instrucción inmediatamente anterior y la reemplazabas por un salto a algún espacio vacío. Allí colocabas la instrucción que acababas de sobrescribir, añadías las instrucciones que querías insertar y, a continuación, ponías un salto de regreso al programa principal. Así, el programa pronto se convertía en una secuencia de saltos del control hacia lugares extraños. Cuando, como casi siempre ocurre, había errores en las correcciones, volvías a usar el mismo truco, empleando algún otro espacio disponible. Como resultado, _la trayectoria de control del programa a través de la memoria pronto adquiría el aspecto de una lata de espaguetis._ ¿Por qué no insertarlas simplemente en la secuencia de instrucciones? ¡Porque entonces tendrías que revisar todo el programa y cambiar todas las direcciones que hacían referencia a cualquiera de las instrucciones desplazadas! ¡Cualquier cosa menos eso!

## Ejemplos

### Sencillo

El siguiente código [BASIC](https://en.wikipedia.org/wiki/BASIC "BASIC"), un programa que imprime del 1 al 100, es un ejemplo relativamente sencillo de código que puede entenderse más fácilmente con un flujo de control estructurado en lugar de usar goto. El uso de `GOTO` para iterar y la falta de sangría dan lugar a un flujo lógico poco claro.

1 i=0
2 i=i+1
3 PRINT i
4 IF i>=100 THEN GOTO 6
5 GOTO 2
6 END

El siguiente código produce el mismo resultado, pero utiliza una [instrucción de bucle](https://en.wikipedia.org/wiki/Loop%5F%28computing%29 "Loop (computing)") estructurada y sangría para mejorar la legibilidad.

1 FOR i=1 TO 100
2     PRINT i
3 NEXT i
4 END

### Más representativo

El siguiente código implementa un [algoritmo de ordenamiento](https://en.wikipedia.org/wiki/Sorting%5Falgorithm "Sorting algorithm") numérico. El uso de instrucciones goto da al flujo de control una naturaleza similar a la de los espaguetis.

  INPUT "How many numbers should be sorted? "; T
  DIM n(T)
  FOR i = 1 TO T
    PRINT "NUMBER:"; i
    INPUT n(i)
  NEXT i
  'Cálculos:
  C = T
E180:
  C = INT(C / 2)
  IF C = 0 THEN GOTO C330
  D = T - C
  E = 1
I220:
  f = E
F230:
  g = f + C
  IF n(f) > n(g) THEN SWAP n(f), n(g)
  f = f - C
  IF f > 0 THEN GOTO F230
  E = E + 1
  IF E > D THEN GOTO E180
  GOTO I220
C330:
  PRINT "The sorted list is"
  FOR i = 1 TO T
    PRINT n(i)
  NEXT i

## Relacionados

### Gran bola de barro

Una gran bola de barro es un [sistema de software](https://en.wikipedia.org/wiki/Software%5Fsystem "Software system") que carece de una arquitectura perceptible. Aunque indeseables desde el punto de vista de la ingeniería de software, estos sistemas son habituales en la práctica debido a las presiones del negocio, la [rotación](https://en.wikipedia.org/wiki/Turnover%5F%28employment%29 "Turnover (employment)") de desarrolladores y la [entropía del software](https://en.wikipedia.org/wiki/Software%5Fentropy "Software entropy"). El término fue popularizado por Brian Foote y Joseph Yoder, aunque atribuyen su acuñación a Brian Marick.

> Una Gran Bola de Barro es una jungla de código espagueti estructurada de forma caótica, descontrolada, descuidada, hecha con cinta adhesiva y alambre. Estos sistemas muestran signos inequívocos de crecimiento no regulado y de reparaciones repetidas y oportunistas. La información se comparte de forma promiscua entre elementos distantes del sistema, a menudo hasta el punto de que casi toda la información importante se vuelve global o se duplica.
>
> Es posible que la estructura general del sistema nunca se haya definido bien.
>
> Y, si lo estuvo, puede haberse erosionado hasta volverse irreconocible. Los programadores con una pizca de sensibilidad arquitectónica rehúyen estos atolladeros. Solo quienes no se preocupan por la arquitectura y, quizá, se sienten cómodos con la inercia de la tarea cotidiana de tapar los agujeros de estos diques que se desmoronan, están a gusto trabajando en tales sistemas.

— Brian Foote y Joseph Yoder, _Big Ball of Mud._ Cuarta Conferencia sobre Lenguajes de Patrones de Programas (PLoP '97/EuroPLoP '97), Monticello, Illinois, septiembre de 1997

### Relacionados con la pasta

Inspirados por la popularidad del _código espagueti_, otros términos relacionados con la [pasta](https://en.wikipedia.org/wiki/Pasta "Pasta") que describen la naturaleza estructural del código incluyen:

Código lasaña

El código [lasaña](https://en.wikipedia.org/wiki/Lasagna "Lasagna") tiene [capas](https://en.wikipedia.org/wiki/Architectural%5Flayer "Architectural layer") tan entrelazadas que realizar un cambio en una capa obliga a cambiar también otras capas.

Código ravioli

El código [ravioli](https://en.wikipedia.org/wiki/Ravioli "Ravioli") se compone de [clases](https://en.wikipedia.org/wiki/Class%5F%28programming%29 "Class (programming)") bien estructuradas que son fáciles de entender por separado, pero que en conjunto dan lugar a un diseño de sistema poco claro.
