En programmation informatique, la programmation spaghetti est un style d'écriture de code source qui favorise l'apparition du syndrome du plat de spaghettis : un code peu clair et qui fait un usage excessif de sauts inconditionnels, d'exceptions en tous sens, de gestion des événements complexes et de threads divers.

INPUT "How many numbers should be sorted? "; T

  DIM n(T)

  FOR i = 1 TO T

    PRINT "NUMBER:"; i

    INPUT n(i)

  NEXT i

  'Calculations:

  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

Comment Organiser son code ?

Contrôle du code

Le contrôle du code est plus qu'un processus de contrôle, mais beaucoup de choses que nous recherchons sont simples et il y en a trop à retenir. Les check-lists nous aident à nous souvenir et informent les contributeurs dès le départ des attentes. Cela aide les contrôleurs à avoir plus de temps à consacrer aux choses les plus importantes et les moins simples, et à réduire le temps consacré aux révisions.

Ces éléments pouvant être automatisés devraient l'être (à l'aide d'outils tels qu'ESLint et ses plugins, ou checkstyle). Les détections et les corrections manuelles ne sont pas fiables, ne s'adaptent pas bien et consomment de l'attention qui serait mieux dépensée ailleurs.

Un nom pour chaque chose et chaque nom utilisé pour une seule chose. Utiliser plusieurs mots pour signifier la même chose, ou le même mot pour signifier des choses différentes gaspille de la concentration et risque de créer de la confusion. Cela s'applique non seulement au code, mais à tout ce qui concerne notre travail, par exemple : noms de variables et de classes, noms de méthodes, données, concepts de domaine, dépôts, configuration et autorisations.

Utilisez des noms bien connus du monde des domaines commerciaux et techniques. Cela permet d'avoir un vocabulaire commun qui rend la communication plus efficace. Évitez d'utiliser ces noms avec des significations différentes.

Utilisez des noms qui ont une signification. La signification est essentielle pour comprendre le code. Les noms génériques tels que « données » ou « valeur » sont trop vagues.

Évitez de laisser des noms pauvres/incohérents s'infiltrer depuis d'autres contextes dans le code. Ces contextes incluent le code hérité, les bibliothèques et les autres applications avec lesquelles nous interagissons. Établissez une limite à l'intérieur de laquelle ces directives de nommage sont respectées et défendez-la de la pollution extérieure.

Il est normal que les noms présentés à l'utilisateur soient différents. Les noms affichés sur l'interface utilisateur/sur la sortie répondent souvent à des exigences et apparaissent dans leur propre contexte. Lorsque ces noms sont médiocres ou inappropriés du point de vue du code, utilisez-en un autre si possible.

Utilisez des acronymes et des abréviations avec parcimonie. Le code est généralement plus clair et plus facile à lire sans ceux-ci. Ceux qui sont universellement acceptés comme id font exception à cette règle, ainsi que ceux du domaine professionnel.

Évitez les noms inutilement longs. Essayez de ne pas être plus long que nécessaire pour transmettre un message. Les noms longs augmentent la nécessité pour les instructions et les appels de méthodes de s'étendre sur plusieurs lignes, ce qui rend le code moins lisible. Cette règle implique d'éviter l'utilisation du nom complet d'un type en tant que nom de variable/paramètre lorsque cela n'est pas nécessaire.

Évitez les noms trop qualifiés. Lorsque le contexte d'un nom a déjà été établi, par exemple en étant dans une classe ou une méthode, il n'est pas nécessaire de reformuler ce contexte. Une « task » (tâche), par exemple, n'a pas besoin d'une « taskCompleted» (tâche accomplie).

Utilisez des noms positifs pour les booléens et évitez la négation dans le nom. Les noms négatifs entraînent des doubles négatifs, ce qui rend les expressions plus difficiles à saisir

(par exemple : enabled: true (activé :vrai) vs disabled: false(désactivé: faux)). Utiliser le mot «not» (Pas) pose le même problème.

Évitez l'usage intensif de « get » comme préfixe du nom de la méthode. Les accesseurs (getters) renvoient des valeurs. Préférez des alternatives plus informatives telles que "request" (requête), "fetch" (cherche), "find" (trouve), "query" (demande), "build" (construit) ou "create" (crée), le cas échéant.

Recherchez des noms distinctifs dans le même contexte. Des noms similaires sont faciles à confondre et rendent le code difficile à lire.

Envisagez de qualifier chaque nom lorsqu'il devient nécessaire de le faire. Cela donne souvent plus de clarté et de précision que la seule qualification pour le distinguer, et il est plus probable que le bon sera choisi pour être utilisé aux endroits appropriés. Exemple : previousFoo & nextFoo , au lieu de previousFoo (précédentFoo) & foo.

Pensez à nommer les choses liées afin qu'elles apparaissent ensemble dans l'ordre alphabétique. Cela facilite la découvrabilité lorsque vous utilisez une convention d'ordre alphabétique. Exemple : data , dataError , dataLoaded .

Les méthodes doivent toujours faire ce que leur nom promet. Les noms de méthodes traduisent les attentes et les utilisateurs seront surpris si elles ne sont pas satisfaites. Évitez de ne pas faire ce que le nom promet, et créez une exception si vous ne pouvez pas le faire.

Utilisez des noms de paramètres de type significatifs lorsqu'une seule lettre n'est pas claire. Cela améliore la lisibilité. Utilisez une convention établie (par exemple, le suffixe «T») pour les distinguer des noms de types.

Évitez les mots composés avec CamelCasing (Ndt : Camel case de l'anglais, littéralement « casse de chameau » est une pratique qui consiste à écrire un ensemble de mots en les liant sans espace ni ponctuation, et en mettant en capitale la première lettre de chaque mot. ). Ce sont des mots simples à part entière, alors vous n'en avez pas besoin. Exemple : callback, password.

Orthographiez correctement et systématiquement. Cela permet d'éviter les erreurs et améliore la possibilité de recherche dans le code. S'il existe plusieurs orthographes correctes (par exemple, clef/clé), suivez les conventions de la plate-forme.

Suivez les conventions existantes autour de vous. Celles-ci peuvent se trouver dans une méthode particulière, dans l'ensemble du code de base ou la technologie/plate-forme avec laquelle vous travaillez. Efforcez-vous de conserver cette cohérence et évitez de faire les choses différemment sans bonne raison.

Source Programmation développez : https://programmation.developpez.com/tutoriel/apprendre-ecrire-meilleur-code/