FutureBasic-Europe

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	INFO \| ACQUÉRIR \| PLAN \| RESSOURCES	Charte Vie Privée Infos Légales

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