Code spaghetti

Le code spaghetti est un code source informatique dont le flux de contrôle est complexe et, par conséquent, difficile à comprendre. Les instructions de contrôle dirigent l'exécution du programme de manière à ressembler à des spaghettis cuits, tordus et emmêlés, plutôt qu'à une structure claire . Ce code est généralement difficile à maintenir .

Étant donné que la logique de contrôle codée via l' instruction `goto` tend à engendrer un flux de contrôle complexe, son utilisation est souvent associée à la qualification de « code spaghetti » . La programmation structurée a été conçue pour éliminer le besoin et l'utilisation de l'instruction `goto`, afin d'éviter la production de code spaghetti. Garantir la création de logiciels de haute qualité , plutôt que de code spaghetti, implique souvent des aspects tels que l'utilisation d'outils plus performants , la formation des développeurs et l'amélioration des processus de développement logiciel .

Le terme « code spaghetti » peut également désigner un anti-modèle dans lequel du code orienté objet est écrit de manière procédurale, par exemple en créant des classes dont les méthodes sont excessivement longues et complexes, ou en abandonnant des concepts orientés objet comme le polymorphisme . La présence de ce type de code spaghetti peut considérablement réduire la compréhensibilité d'un système.

On ignore la date d'apparition de l'expression « code spaghetti » . Martin Hopkins y fait référence dès 1972, écrivant que « la principale motivation derrière l'élimination de l'instruction goto est l'espoir que les programmes résultants ne ressemblent pas à un plat de spaghettis » . Dans son ouvrage de 1978 , *A primer on disciplined programming using PL/I, PL/CS, and PL/CT* , Richard Conway décrit des programmes qui « ont la même structure logique claire qu'une assiette de spaghettis » une expression reprise dans son livre de 1979, *An Introduction to Programming*, coécrit avec David Gries . Dans l'article de 1988, *A spiral model of software development and enhancement* , le terme est utilisé 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 son ouvrage de 1979 intitulé Structured programming for the COBOL programmer , l'auteur Paul Noll utilise les expressions « code spaghetti » et « 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 les anciens programmes ayant des « fichiers fragmentés et dispersés ».

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

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

Si, pour corriger une erreur, vous vouliez insérer des instructions omises, vous preniez l'instruction précédente et la remplaciez par un transfert vers un espace vide. Vous y insériez l'instruction que vous veniez d'écraser, ajoutiez les instructions à insérer, puis effectuiez un transfert de retour vers le programme principal. Ainsi, le programme devenait rapidement une suite de sauts de contrôle vers des emplacements étranges. Lorsque, comme c'était presque toujours le cas, des erreurs se produisaient lors des corrections, vous réutilisiez la même astuce, en utilisant un autre espace disponible. De ce fait, le chemin d'accès au programme à travers la mémoire prenait rapidement l'apparence d'une boîte de spaghettis. Pourquoi ne pas simplement les insérer dans la séquence d'instructions ? Parce qu'il faudrait alors parcourir tout le programme et modifier toutes les adresses qui faisaient référence aux instructions déplacées ! À éviter absolument !

Le code BASIC suivant , un programme qui affiche les nombres de 1 à 100, est un exemple relativement simple de code plus facile à comprendre avec une structure de contrôle claire plutôt qu'avec l'instruction `goto`. L'utilisation de GOTOboucles `for` et l'absence d'indentation rendent le flux logique peu limpide.

10 i = 0 20 i = i + 1 30 AFFICHER i 40 SI i >= 100 ALORS ALLER À 60 50 ALLER À 20 60 FIN

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

10 POUR i = 1 À 100 20 AFFICHER i 30 SUIVANT i 40 FIN

Le code suivant implémente un algorithme de tri numérique . L'utilisation d'instructions goto donne au flux de contrôle un aspect complexe, semblable à un spaghetti.

SAISIR "Combien de nombres faut-il trier ?" ; T DIM n ( T ) POUR i = 1 À T AFFICHER "NOMBRE :" ; i SAISIR n ( i ) SUIVANT i 'Calculs : C = T E180 : C = ENT ( C / 2 ) SI C = 0 ALORS ALLER À C330 D = T - C E = 1 I220 : f = E F230 : g = f + C SI n ( f ) > n ( g ) ALORS ÉCHANGER n ( f ), n ( g ) f = f - C SI f > 0 ALORS ALLER À F230 E = E + 1 SI E > D ALORS ALLER À E180 ALLER À I220 C330 : AFFICHER "La liste triée est :" POUR i = 1 À T AFFICHER n ( i ) SUIVANT i

Un système logiciel « boue de boue » est un système dépourvu d'architecture perceptible. Bien qu'indésirables du point de vue du génie logiciel, de tels systèmes sont courants en pratique en raison des contraintes commerciales, du roulement du personnel de développement et de l'entropie logicielle . Le terme a été popularisé par Brian Foote et Joseph Yoder, qui attribuent toutefois sa création à Brian Marick.

Un système chaotique et désordonné est une jungle tentaculaire et brouillonne, un véritable fouillis de code spaghetti. Ces systèmes présentent des signes indéniables de croissance anarchique et de réparations hâtives et répétées. L'information est partagée sans discernement entre les éléments distants du système, souvent au point que la quasi-totalité des informations importantes devient globale ou dupliquée.

Il se peut que la structure globale du système n'ait jamais été clairement définie.

Si tel était le cas, il serait probablement devenu méconnaissable. Les programmeurs dotés d'un minimum de sensibilité architecturale fuient ces bourbiers. Seuls ceux qui se désintéressent de l'architecture et qui, peut-être, se complaisent dans la routine quotidienne consistant à colmater les brèches de ces digues défaillantes, acceptent de travailler sur de tels systèmes.

Inspirés par la popularité du code spaghetti , d'autres termes dérivés de « pâtes » qui décrivent la nature structurelle du code incluent :

Code des lasagnes

Le code Lasagna comporte des couches tellement imbriquées que modifier une couche nécessite également de modifier les autres couches.

Code des raviolis

Le code Ravioli comprend des classes bien structurées , faciles à comprendre individuellement, mais dont la combinaison donne une conception système peu claire.