Comme beaucoup à mon époque (fin des 80's) j'ai commencé en BASIC avec numéro de lignes. Le GOTO était pour ainsi dire la seule instruction de contrôle de flot. IF et GOTO partout, pas de WHILE ni de FOR.
Le code était vraiment compliqué à comprendre à posteriori, et les effets de bords très courants. Mais le soucis c'est que quand tu es habitué à coder comme ça, c'est très dur de t'adapter à autre chose, et l'effort est important pour changer. Je suppose que la malédiction du GOTO vient de l'époque où on a cherché à faire basculer tout le monde.
Maintenant le GOTO utilisé à bon escient et avec parcimonie reste un outil simple et efficace.
dans les cas où il rend le code plus facile à lire/comprendre/maintenir, on peut (devrait ?) l'utiliser
En général il est utilisé comme moins pire que :
- trop de if() imbriqués pour vérifier des codes de retour successifs
- trop de return() un peu partout dans la fonction
Chacun mettra "trop" à ses propres valeurs :)
Un GOTO est finalement juste une instruction JMP.
Et oui. On sait bien que for() et while() sont traduits en assembleur en IF et JMP (souvent dans la même instruction tellement c'est courant).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: goto return cave
Posté par gUI (Mastodon) . En réponse au journal Is return the new goto ?. Évalué à 8. Dernière modification le 27 janvier 2024 à 10:49.
Comme beaucoup à mon époque (fin des 80's) j'ai commencé en BASIC avec numéro de lignes. Le GOTO était pour ainsi dire la seule instruction de contrôle de flot. IF et GOTO partout, pas de WHILE ni de FOR.
Le code était vraiment compliqué à comprendre à posteriori, et les effets de bords très courants. Mais le soucis c'est que quand tu es habitué à coder comme ça, c'est très dur de t'adapter à autre chose, et l'effort est important pour changer. Je suppose que la malédiction du GOTO vient de l'époque où on a cherché à faire basculer tout le monde.
Maintenant le GOTO utilisé à bon escient et avec parcimonie reste un outil simple et efficace.
En général il est utilisé comme moins pire que :
- trop de
if()imbriqués pour vérifier des codes de retour successifs- trop de
return()un peu partout dans la fonctionChacun mettra "trop" à ses propres valeurs :)
Et oui. On sait bien que
for()etwhile()sont traduits en assembleur enIFetJMP(souvent dans la même instruction tellement c'est courant).En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.