Code spaghetti.

Le code spaghetti est du code source informatique qui encode un flot de contrôle alambiqué et, par conséquent, difficile à comprendre. Les instructions de contrôle dirigent l'exécution du programme d'une manière qui, au lieu de présenter une structure de qualité, ressemble à des spaghettis cuits, entremêlés et emmêlés. Ce code a tendance à être difficile à maintenir.

Étant donné que la logique de flot de contrôle encodée au moyen de l'instruction goto a tendance à produire un flot de contrôle alambiqué, l'usage de goto est souvent associé à une qualification de code spaghetti. La pratique de la programmation structurée a été conçue pour éliminer le besoin et l'usage de l'instruction goto, comme l'un des moyens d'éviter la production de code spaghetti. Garantir la création d'un logiciel de haute qualité, plutôt que de code spaghetti, fait souvent intervenir des aspects tels que l'utilisation de meilleurs outils, la formation des développeurs et l'amélioration des processus de développement logiciel.

Le code spaghetti peut aussi désigner un anti-pattern dans lequel du code orienté objet est écrit dans un style procédural, par exemple en créant des classes dont les méthodes sont excessivement longues et désordonnées, ou en renonçant aux concepts orientés objet tels que le polymorphisme. La présence de cette forme de code spaghetti peut réduire considérablement la compréhensibilité d'un système.

On ne sait pas exactement quand l'expression code spaghetti a été forgée. Martin Hopkins y a fait une référence précoce dans ce contexte en 1972, écrivant que la « principale motivation derrière l'élimination de l'instruction goto est l'espoir que les programmes résultants ne ressembleront pas à un bol de spaghettis ». Dans l'ouvrage de 1978 A primer on disciplined programming using PL/I, PL/CS, and PL/CT, Richard Conway décrivait des programmes ayant « la même structure logique soignée qu'une assiette de spaghettis », une formule reprise dans l'ouvrage de 1979 An Introduction to Programming qu'il a coécrit avec David Gries. Dans l'article de 1988 A spiral model of software development and enhancement, le terme est employé pour décrire l'ancienne pratique du modèle « code and fix », qui manquait de planification et a finalement conduit au développement du modèle en cascade. Dans l'ouvrage de 1979 Structured programming for the COBOL programmer, l'auteur Paul Noll utilise les expressions code spaghetti et rat's nest (« nid de rats ») comme synonymes pour décrire un code source mal structuré.

Lors de la conférence Ada – Europe '93, Ada a été décrit comme forçant le programmeur à « produire du code compréhensible, plutôt que du code spaghetti », en raison de son mécanisme restrictif de propagation des exceptions.

Dans une publication de 1980 du Bureau national des normes des États-Unis, l'expression programme spaghetti a été utilisée pour décrire d'anciens programmes ayant des « fichiers fragmentés et dispersés ».

Dans une parodie sur les langages informatiques publiée en 1981 dans The Michigan Technic, intitulée « BASICally speaking...FORTRAN bytes!! », l'auteur décrivait FORTRAN en affirmant qu'« il est entièrement constitué de code spaghetti ».

Richard Hamming a décrit dans ses cours l'étymologie du terme dans le contexte de la programmation des débuts en codes binaires :

Si, en corrigeant une erreur, vous vouliez insérer des instructions omises, vous preniez l'instruction immédiatement précédente et vous la remplaciez par un saut vers un espace vide. Là, vous placiez l'instruction que vous veniez d'écraser, vous ajoutiez les instructions que vous vouliez insérer, puis vous faisiez suivre d'un saut de retour vers le programme principal. Ainsi, le programme devenait rapidement une suite de sauts du contrôle vers des endroits étranges. Lorsque, comme c'est presque toujours le cas, il y avait des erreurs dans les corrections, vous utilisiez alors de nouveau la même astuce, en vous servant d'un autre espace disponible. En conséquence, le chemin de contrôle du programme à travers la mémoire prenait bientôt l'apparence d'une boîte de spaghettis. Pourquoi ne pas simplement les insérer dans le fil des instructions ? Parce qu'il aurait alors fallu reprendre tout le programme et modifier toutes les adresses qui renvoyaient à l'une des instructions déplacées ! Tout sauf ça !

Le code BASIC suivant, un programme qui affiche les nombres de 1 à 100, est un exemple relativement simple de code que l'on peut comprendre plus facilement avec un flot de contrôle structuré plutôt qu'en utilisant goto. L'utilisation de GOTO pour les boucles et l'absence d'indentation rendent le déroulement logique peu clair.

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

Le code suivant produit le même résultat, mais utilise une instruction de boucle structurée et l'indentation pour améliorer la lisibilité.

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

Le code suivant implémente un algorithme de tri numérique. L'utilisation d'instructions goto donne au flot de contrôle un caractère de type spaghetti.

  INPUT "How many numbers should be sorted? "; T
  DIM n(T)
  FOR i = 1 TO T
    PRINT "NUMBER:"; i
    INPUT n(i)
  NEXT i
  'Calculs :
  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

Une grande boule de boue (« big ball of mud ») est un système logiciel dépourvu d'architecture perceptible. Bien qu'indésirables du point de vue du génie logiciel, de tels systèmes sont fréquents en pratique en raison des pressions commerciales, du renouvellement des développeurs et de l'entropie logicielle. Le terme a été popularisé par Brian Foote et Joseph Yoder, bien qu'ils en attribuent la paternité à Brian Marick.

Une Big Ball of Mud est une jungle de code spaghetti structurée au hasard, tentaculaire, négligée, rafistolée au ruban adhésif et au fil de fer. Ces systèmes présentent des signes indéniables de croissance non régulée et de réparations répétées et expéditives. L'information y est partagée sans retenue entre des éléments éloignés du système, souvent au point que presque toute l'information importante devient globale ou dupliquée.

La structure d'ensemble du système n'a peut-être jamais été bien définie.

Et si elle l'a été, elle s'est peut-être érodée au point d'être méconnaissable. Les programmeurs ayant la moindre sensibilité architecturale fuient ces bourbiers. Seuls ceux qui se désintéressent de l'architecture et qui, peut-être, s'accommodent de l'inertie de la corvée quotidienne consistant à colmater les trous de ces digues qui cèdent, se contentent de travailler sur de tels systèmes.

Inspirés par la popularité du code spaghetti, d'autres termes inspirés des pâtes et décrivant la nature structurelle du code incluent :

Code lasagne

Le code lasagne comporte des couches si imbriquées que modifier une couche oblige à modifier aussi les autres.

Code ravioli

Le code ravioli est composé de classes bien structurées, faciles à comprendre isolément, mais qui, combinées, aboutissent à une conception du système peu claire.