[EN] [IT]
[INFO] [ACQUÉRIR] [PLAN] [RESSOURCES]
CHAPITRE
APPRENDRE À PROGRAMMER AVEC FUTUREBASIC
NOTES

Les branchements I

GOTO et GOSUB

Leçon 10 : Les branchements inconditionnels

GOTO / GOSUB
On vient de voir que le cheminement dʼun programme pouvait être soumis à des conditions, en lʼoccurrence la valeur de certaines variables. Le langage BASIC offre aussi des commandes pour diriger le flux du programme où bon vous semble ou presque. Les instructions GOTO et GOSUB permettent des branchements inconditionnels.

Dans le langage BASIC traditionnel, ces commandes sont presque tout le temps apprises dès la première leçon, car leur facilité de mise en œuvre donne au débutant un moyen instantané de contrôler le flux du programme. Avec FutureBASIC cependant, ces commandes sont à proscrire et je suis tenté dʼajouter presque au plus haut point. Nous ne nous attarderons pas sur les nombreuses raisons pour bannir ces commandes, mais sachez quʼelles peuvent transformer votre code en un écheveau inextricable, pénible à suivre, à comprendre, à déboguer et à faire évoluer. Elles sont les principales responsables de ce quʼil est convenu dʼappeler la programmation spaghetti.

GOTO dirige instantanément le flux du programme à une ligne de code de votre choix. Mais comment désigne-t-on une ligne spécifique du code source ?

Autrefois, les choses auraient pu vous sembler plus simples puisque chaque ligne de code était numérotée, et il suffisait dʼindiquer dans la commande GOTO le numéro de ligne à laquelle on souhaitait dérouter le programme. Les numéros de ligne sont tombés en désuétude, dʼailleurs tous ces numéros nʼavaient pas forcément une utilité pour le programmeur, et on utilise aujourdʼhui des étiquettes beaucoup plus parlantes pour identifier des parties précises du code source.

GOSUB et RETURN sont deux commandes indissociables. De même que GOTO, GOSUB dirige le flux du programme vers une ligne de code de votre choix, où les instructions sont exécutées normalement jusquʼà ce que lʼindispensable commande RETURN soit rencontrée, à ce moment-là, le flux du programme est redirigé sur lʼinstruction qui suit la dernière commande GOSUB qui a provoqué le branchement.

Examinez lʼexemple prétexte suivant :

_nbEleves = 40
_nbTrimestres = 4

DIM
nom(_nbEleves) AS STR255
DIM notes(_nbEleves,_nbTrimestres) AS DOUBLE
DIM nomATrouver AS STR255
DIM AS SHORT i

nomATrouver = "Durand"
i = 1
"entrée boucle"
LONG IF nom(i) = nomATrouver
  GOSUB "trouvé"
  GOTO "sortie boucle"
XELSE
  i = i + 1
  IF i > _nbEleves THEN GOSUB "non trouvé"
  IF i <= _nbEleves THEN GOTO "entrée boucle" ELSE GOTO "sortie boucle"
END IF
"sortie boucle"
END

"trouvé"
PRINT "Moyenne de " + nomATrouver;
PRINT notes(i,0)
RETURN

"non trouvé"
PRINT "Elève introuvable"
RETURN

Les différentes parties du code sont identifiées au moyen dʼétiquettes. "entrée boucle"; "sortie boucle"; "trouvé" et "non trouvé" constituent les quatre étiquettes utilisées dans le programme ci-dessus. Une étiquette (ou label en anglais) nʼest autre quʼune chaîne de caractères littérale placée entre guillemets sur une ligne isolée qui identifie de manière unique un point du code source.

Vous avez très certainement noté le mot-clé END après lʼétiquette "sortie boucle". Cette commande met fin au programme et elle est, dans lʼexemple ci-dessus, indispensable, sinon le programme continuerait sa course et exécuterait les instructions qui la suivent jusquʼau premier RETURN rencontré où il serait bien en peine de trouver un endroit où il doit retourner provoquant ainsi un crash du programme. Comme on le voit, les bouts de code appelés par GOSUB sont comme des petits modules en dehors du programme principal.

Lʼinstruction GOSUB offre la première forme de structuration possible dʼun programme en permettant lʼexécution de tâches bien définies que lʼon peut déclencher à loisir depuis le programme principal. Il est aisé de comprendre que ces routines permettent dʼéviter lʼécriture des mêmes lignes de code à différents endroits du code source, mais dans un programme de plusieurs milliers de lignes, cette organisation nʼest plus très efficace, il va vous falloir naviguer dʼun endroit à un autre du code source sans perdre le fil du raisonnement en cours pour comprendre ce qui se passe vraiment. La valeur dʼune variable peut être modifiée par une routine qui en appelle une autre, qui en appelle une autre et ainsi de suite… une variable pourrait ainsi subir diverses altérations avant que le programme ne poursuive à nouveau son cours depuis lʼendroit où le premier branchement a eu lieu.

Lʼintérêt toutefois dʼune telle organisation est dʼobliger le programmeur à penser son programme en déterminant les tâches élémentaires à accomplir pour réaliser des tâches plus complexes et résoudre les problèmes qui lui sont posés. Lʼinterdépendance de toutes les parties du code nʼest cependant pas ce quʼil y a de mieux, vous vous en rendrez vite compte le jour où vous déciderez de reprendre un programme pour y ajouter des fonctionnalités que vous nʼaviez pas prévues au départ. Nul doute que vous vous direz à ce moment-là quʼidéalement, il serait plus judicieux dʼavoir des routines qui offrent le minimum de chances dʼaltérer de manière inattendue la valeur de certaines variables vitales au programme, des routines qui seraient comme de véritables petits programmes indépendants spécialisés avec lesquels le programme principal pourrait communiquer.



[Precédent] [Table des Matières] [Suivant]
{Note}
© 2000 Pix&Mix
Tous droits réservés

FutureBASIC est une marque déposée appartenant à Staz Software, Inc et utilisée avec permission.