En fait, si tu parles de "totem" et que tu affirmes que le code était meilleur avec des "goto", tu fais les questions et les réponses. En gros, tu es en désaccord avec les concepteurs de ces langages, et voila.
Parmi les avantages de ce système, tu as un allègement de la syntaxe (plus besoin de "return"), une écriture plus intuitive des fonctions à une ligne (type fonctions mathématiques), style "int square(x) x*x ", et une diminution très forte des bugs de post-conditions (par exemple si tu as un if(answer < 0) answer = 0, tu veux que ça s'applique à tous les returns, ce qui est n'as possible si tes returns sont dispersés). Idem pour le débuggage, tu sais où mettre un point d'arrêt si tu veux savoir ce qui sort de ta fonction. n
Le désavantage majeur, tu l'as noté, c'est quand tu as des cas où le traitement n'est pas nécessaire (if (i == 0) return 0), que tu vas devoir remplacer par un niveau d'imbrication supplémentaire.
Je ne pense pas que ce genre de décisions de design soient prises à la légère : des développeurs expérimentés ont estimé le rapport coût/bénéfices de ce choix, éclairé par leur expérience, et ont pensé que ce rapport était avantageux. Chaque langage a ses paradigmes, if(i==0) return -1 else return i , c'est pareil que if (i==0) i = -1; return i; et une forme peut être privilégiée dans chaque langage pour tout un tas de raisons.
# Tu peux faire les questions et les réponses...
Posté par arnaudus . En réponse au journal Is return the new goto ?. Évalué à 9.
En fait, si tu parles de "totem" et que tu affirmes que le code était meilleur avec des "goto", tu fais les questions et les réponses. En gros, tu es en désaccord avec les concepteurs de ces langages, et voila.
Parmi les avantages de ce système, tu as un allègement de la syntaxe (plus besoin de "return"), une écriture plus intuitive des fonctions à une ligne (type fonctions mathématiques), style "int square(x) x*x ", et une diminution très forte des bugs de post-conditions (par exemple si tu as un if(answer < 0) answer = 0, tu veux que ça s'applique à tous les returns, ce qui est n'as possible si tes returns sont dispersés). Idem pour le débuggage, tu sais où mettre un point d'arrêt si tu veux savoir ce qui sort de ta fonction. n
Le désavantage majeur, tu l'as noté, c'est quand tu as des cas où le traitement n'est pas nécessaire (if (i == 0) return 0), que tu vas devoir remplacer par un niveau d'imbrication supplémentaire.
Je ne pense pas que ce genre de décisions de design soient prises à la légère : des développeurs expérimentés ont estimé le rapport coût/bénéfices de ce choix, éclairé par leur expérience, et ont pensé que ce rapport était avantageux. Chaque langage a ses paradigmes, if(i==0) return -1 else return i , c'est pareil que if (i==0) i = -1; return i; et une forme peut être privilégiée dans chaque langage pour tout un tas de raisons.