Je trouve que le return n’est quand même pas aussi problématique que le goto, mais c’est sûrement une question de goût, de façon de réfléchir et d’éducation. Il subsiste sûrement des aficionados du goto. Il y en avait encore il y a 15 ans en tous cas.
Le return par contre, même s’il est effectivement beaucoup plus élégant que ce soit la dernière ligne d’une fonction qui soit implicitement la valeur retournée par la fonction, comme c’est l’usage, entre autre en Bash/shell (qui de toute manière ne sait retourner qu’un entier unique), le return permet de sortir de la fonction « avant la fin », à l’instar d’un "break" dans une boucle, et ça peut vraiment être utile, je trouve. Si par exemple on a un algorithme qui convient pour implémenter une fonction, mais que celui-ci ne fonctionne malheureusement pour une (ou quelques) valeur(s) connues, et que par ailleurs la valeur à retourner pour cette valeur d’entrée est constante, immuable, alors c’est quand même plaisant de ne pas avoir à chercher un algorithme « parfait » qui permettrait de traiter aussi cette valeur (algo qui sera probablement moins performant quand bien même il sera relativement évident...), ou bien de devoir s’appliquer à ce que le reste du code ne puisse jamais passer cette valeur à la fonction. Ça c’est pour le return en tout début de fonction. Mais c’est également très pratique en plein milieu de la fonction, bien que je n’ai pas d’exemple en tête là sur le moment.
C’est sûr qu’en LISP on n’a pas à utiliser return, vu que la fonction « se retourne elle-même » si j’ose dire (et j’ose, c’est à ça qu’on me reconnaît !), mais LISP est quand même très particulier, une programmation purement fonctionnelle n’est quand même pas l’approche la plus intuitive qui soit, comparé à l’approche algorithmique. Et j’ai l’impression que pour le commun des codeurs c’est une approche hybride, qui associe les deux concepts (et d’autres), qui paraît la plus naturelle. Il me semble d’ailleurs avoir lu que LISP était particulièrement apprécié dans le domaine de la méta-programmation. Je ne suis pas assez compétent pour affirmer que c’est véridique/pertinent, mais de mon point de vue ça semble assez évident. Tout autant qu’à l’inverse faire de la méta-programmation avec des goto ça doit sûrement être fortement perturbant, level paradoxe spatio-temporel ! ^^
# goto return cave
Posté par Marotte ⛧ . En réponse au journal Is return the new goto ?. Évalué à 6. Dernière modification le 26 janvier 2024 à 23:09.
Je trouve que le return n’est quand même pas aussi problématique que le goto, mais c’est sûrement une question de goût, de façon de réfléchir et d’éducation. Il subsiste sûrement des aficionados du goto. Il y en avait encore il y a 15 ans en tous cas.
Le return par contre, même s’il est effectivement beaucoup plus élégant que ce soit la dernière ligne d’une fonction qui soit implicitement la valeur retournée par la fonction, comme c’est l’usage, entre autre en Bash/shell (qui de toute manière ne sait retourner qu’un entier unique), le return permet de sortir de la fonction « avant la fin », à l’instar d’un "break" dans une boucle, et ça peut vraiment être utile, je trouve. Si par exemple on a un algorithme qui convient pour implémenter une fonction, mais que celui-ci ne fonctionne malheureusement pour une (ou quelques) valeur(s) connues, et que par ailleurs la valeur à retourner pour cette valeur d’entrée est constante, immuable, alors c’est quand même plaisant de ne pas avoir à chercher un algorithme « parfait » qui permettrait de traiter aussi cette valeur (algo qui sera probablement moins performant quand bien même il sera relativement évident...), ou bien de devoir s’appliquer à ce que le reste du code ne puisse jamais passer cette valeur à la fonction. Ça c’est pour le return en tout début de fonction. Mais c’est également très pratique en plein milieu de la fonction, bien que je n’ai pas d’exemple en tête là sur le moment.
C’est sûr qu’en LISP on n’a pas à utiliser return, vu que la fonction « se retourne elle-même » si j’ose dire (et j’ose, c’est à ça qu’on me reconnaît !), mais LISP est quand même très particulier, une programmation purement fonctionnelle n’est quand même pas l’approche la plus intuitive qui soit, comparé à l’approche algorithmique. Et j’ai l’impression que pour le commun des codeurs c’est une approche hybride, qui associe les deux concepts (et d’autres), qui paraît la plus naturelle. Il me semble d’ailleurs avoir lu que LISP était particulièrement apprécié dans le domaine de la méta-programmation. Je ne suis pas assez compétent pour affirmer que c’est véridique/pertinent, mais de mon point de vue ça semble assez évident. Tout autant qu’à l’inverse faire de la méta-programmation avec des goto ça doit sûrement être fortement perturbant, level paradoxe spatio-temporel ! ^^