Et le mec disait en gros « Parfois il est plus utile d'utiliser un GOTO bien placé et bien optimisé que des imbrications de if et else qui rendent votre application illisible, non-optimisée, non-optimisable et donne des codes assembleurs de 15 km »
En même temps, moi je suis assez fan des « if » imbriqués, aussi. En fait, je trouve que l'essence même de la programmation structurée se trouve là-dedans : pouvoir identifier au niveau formel la route suivie par le code.
Je trouve ça beaucoup plus propre que de tout mettre à plat et de quitter la fonction avec un return (qui est un goto déguisé, quand il ne se trouve pas en fin de fonction) dès que quelque chose cloche. D'abord, parce que quand on élabore un processus complexe où chaque opération est dépendante de la première, il devient très difficile de déconstruire ce que l'on a fait dans les lignes précédentes si une condition vient à ne pas être remplie et qu'il faut avorter le processus, ensuite parce que la prochaine action ne peut être déterminée qu'en connaissant l'état de la machine au run-time.
À contrario, des « if » imbriqués ne sont pas si illisbles que çà, surtout s'ils sont proprement indentés : en choisissant par exemple une largeur de 4 caractères, on peut descendre jusqu'au dixième niveau d'imbrication − rarement atteint en pratique − sans dépasser la moitié de la zone d'édition sur un terminal ou une vieille imprimante matricielle en 80 colonnes. En travaillant sous X-Window avec un écran plat moderne au format 16:9, j'ai un terminal de 208 colonnes. Je peux en ouvrir deux cotes à cotes et avoir encore de la place dans chacun d'eux.
En outre, cela structure le code dès le niveau syntaxique : quoi qu'il se passe, tout ce qui est dépendant d'une condition se trouve à l'intérieur d'un bloc. Ça permet entre autre d'utiliser facilement les fonctions de repliement de son éditeur de texte préféré. On pourrait même imaginer combiner cette fonction de repliement à l'état du debugger si on pouvait garantir que tous les programmes sources étaient rédigés de cette façon.
Ça permet également de poser tout de suite les post-conditions : par exemple, si la première étape d'un long cheminement consiste à ouvrir un fichier, eh bien je teste la validité du handler dans mon if(), j'ouvre le bloc et je place tout de suite le close() à la fin. Ensuite, j'insère la suite de mon code entre le début du bloc et ce close(). De fait, je suis sûr de ne jamais l'oublier, que la suite du programme réussisse ou échoue. Ça permet de maintenir un programme sur de nombreuses années, y compris par plusieurs personnes différentes, qui n'ont pas besoin de savoir a priori que cela a été écrit auparavant. Dans le cas contraire, il faut mettre en place une procédure de sortie anticipée et penser à la remplir au fur et à mesure que le code évolue.
[^] # Re: GOTO : Nostalgie...
Posté par Obsidian . En réponse au journal Sortie de PHP 5.3. Évalué à 5.
En même temps, moi je suis assez fan des « if » imbriqués, aussi. En fait, je trouve que l'essence même de la programmation structurée se trouve là-dedans : pouvoir identifier au niveau formel la route suivie par le code.
Je trouve ça beaucoup plus propre que de tout mettre à plat et de quitter la fonction avec un return (qui est un goto déguisé, quand il ne se trouve pas en fin de fonction) dès que quelque chose cloche. D'abord, parce que quand on élabore un processus complexe où chaque opération est dépendante de la première, il devient très difficile de déconstruire ce que l'on a fait dans les lignes précédentes si une condition vient à ne pas être remplie et qu'il faut avorter le processus, ensuite parce que la prochaine action ne peut être déterminée qu'en connaissant l'état de la machine au run-time.
À contrario, des « if » imbriqués ne sont pas si illisbles que çà, surtout s'ils sont proprement indentés : en choisissant par exemple une largeur de 4 caractères, on peut descendre jusqu'au dixième niveau d'imbrication − rarement atteint en pratique − sans dépasser la moitié de la zone d'édition sur un terminal ou une vieille imprimante matricielle en 80 colonnes. En travaillant sous X-Window avec un écran plat moderne au format 16:9, j'ai un terminal de 208 colonnes. Je peux en ouvrir deux cotes à cotes et avoir encore de la place dans chacun d'eux.
En outre, cela structure le code dès le niveau syntaxique : quoi qu'il se passe, tout ce qui est dépendant d'une condition se trouve à l'intérieur d'un bloc. Ça permet entre autre d'utiliser facilement les fonctions de repliement de son éditeur de texte préféré. On pourrait même imaginer combiner cette fonction de repliement à l'état du debugger si on pouvait garantir que tous les programmes sources étaient rédigés de cette façon.
Ça permet également de poser tout de suite les post-conditions : par exemple, si la première étape d'un long cheminement consiste à ouvrir un fichier, eh bien je teste la validité du handler dans mon if(), j'ouvre le bloc et je place tout de suite le close() à la fin. Ensuite, j'insère la suite de mon code entre le début du bloc et ce close(). De fait, je suis sûr de ne jamais l'oublier, que la suite du programme réussisse ou échoue. Ça permet de maintenir un programme sur de nombreuses années, y compris par plusieurs personnes différentes, qui n'ont pas besoin de savoir a priori que cela a été écrit auparavant. Dans le cas contraire, il faut mettre en place une procédure de sortie anticipée et penser à la remplir au fur et à mesure que le code évolue.