Java va

Il y a une vieille blague de programmeur qui dit quelque chose comme ceci: Un programmeur en colère dit au deuxième programmeur, "Allez en enfer!" Le deuxième programmeur répond avec une répulsion évidente, "Ugh, vous avez utilisé goto!" Le point de cet humour ringard est que pour de nombreux programmeurs, l'utilisation de "goto" est à peu près la pire infraction que l'on puisse commettre.

Il y a plusieurs raisons pour lesquelles le goto est si peu estimé parmi les développeurs de logiciels. L'article d'Edsger W. Dijkstra, A Case Against the GO TO Statement, est un traité relativement ancien sur les méfaits des abus de GOTO. Dans cet article, Dijkstra déclare: "[Je suis devenu] convaincu que l'instruction go to devrait être supprimée de tous les langages de programmation de« niveau supérieur »." La lettre Go To Statement de Dijkstra jugée nuisible a non seulement fustigé la déclaration goto, mais a également lancé une tendance informatique populaire à utiliser l'expression «considéré comme nuisible» (bien que ces deux mots aient apparemment été utilisés en dehors de la programmation avant cela).

De nombreux programmeurs depuis Dijkstra ont été mordus par certains des problèmes de maintenabilité associés à l'utilisation des instructions goto dans certains langages. D'autres programmeurs ont entendu ces histoires ou se sont fait tellement entendre le "Tu n'utiliseras pas goto" qu'ils n'ont pas besoin d'en ressentir les inconvénients pour croire qu'ils ne devraient pas utiliser GOTO.

Bien que la déclaration goto semble avoir généralement mauvaise réputation, elle n'est pas sans ses partisans. Frank Rubin a écrit une réponse à la déclaration Go To de Dijkstra considérée comme nuisible(Mars 1968) appelé GOTO considéré comme nocif «considéré comme nocif (mars 1987). Dans cette lettre, Rubin a écrit que la lettre de Dijkstra avait un effet si dramatique sur les programmeurs que "la notion que le GOT0 est nuisible est acceptée presque universellement, sans question ni doute". De cette observation, Rubin a écrit: «Cela a causé un préjudice incalculable au domaine de la programmation, qui a perdu un outil efficace. C'est comme les bouchers interdisant les couteaux parce que les ouvriers se coupent parfois». Notez que Dijkstra a répondu à la lettre de Rubin avec Une correspondance quelque peu décevante. La page Go To de Cunningham & Cunningham Wiki dit ceci à propos de la déclaration goto: "L'apprenti l'utilise sans réfléchir. Le compagnon l'évite sans réfléchir. Le maître l'utilise pensivement."

Il existe de nombreuses autres ressources qui couvrent les avantages et les inconvénients de l'utilisation de l'instruction goto. Je n'ai pas l'intention de relancer ce débat ici à part la brève présentation de l'histoire des débuts de la controverse déjà couverte. J'ai entendu certains développeurs Java déclarer que Java n'avait pas de déclaration goto et c'est ce dont je veux parler dans le reste de ce blog.

Java réserve "goto" comme mot clé réservé. Cependant, il s'agit d'un mot clé inutilisé. Cela signifie que même si le mot-clé ne fait rien de productif, c'est aussi un mot qui ne peut pas être utilisé dans le code pour les noms de variables ou d'autres constructions. Par exemple, le code suivant ne sera pas compilé:

package dustin.examples; /** * Class demonstrating Java's goto-like functionality. */ public class JavaGotoFunctionality { /** * Main executable function. * * @param arguments Command-line arguments: none expected. */ public static void main(final String[] arguments) { final String goto = "Go to bed!"; } } 

Si j'essaie de compiler ce code, je vois une erreur comme celle montrée dans la capture d'écran suivante.

Le message d'erreur «attendu» avec un pointeur sur l'espace avant «goto» donne à un développeur Java expérimenté suffisamment d'indices pour se rendre compte rapidement qu'il y a quelque chose qui ne va pas dans l'utilisation de «goto». Cependant, cela peut ne pas être aussi évident pour quelqu'un de nouveau sur Java.

Je n'utilise généralement pas la construction goto, mais je reconnais également qu'il existe des situations dans lesquelles son utilisation rend le code plus lisible et utilise des solutions de contournement moins folles que de ne pas l'utiliser. En Java, cela a également été réalisé et un support est fourni pour certaines des situations les plus courantes dans lesquelles une instruction goto serait la plus utile et serait probablement préférable aux alternatives. Les exemples les plus évidents en sont les déclarations étiquetées breaket étiquetées continue. Ceux-ci sont abordés et illustrés dans la section Tutoriels Java Instructions de branchement.

La possibilité d'étiqueter une instruction particulière, puis d'avoir le breakou de l' continueappliquer à cette instruction plutôt que son instruction la plus immédiate (comme une instruction non étiquetée breakou le continuefait) est particulièrement utile dans les cas où les boucles imbriquées nécessiteraient autrement plus de code et un code plus complexe pour accomplir la même chose chose. J'ai constaté que je peux souvent repenser mes structures de données et mon code pour éviter de telles situations, mais ce n'est pas toujours pratique.

Une autre bonne ressource liée à l'utilisation des fonctionnalités de type goto en Java est le 13 juin 2000 JDC Tech Tip Goto Statements and Java Programming. Comme le souligne cette astuce, les étiquettes peuvent en fait être utilisées pour n'importe quel bloc et ne sont pas limitées à breaket continue. Cependant, selon mon expérience, la nécessité de cette approche en dehors de breaket continueest beaucoup moins courante.

Une observation importante à propos des étiquettes est que l'exécution du code ne revient pas littéralement à cette étiquette lorsque le break somelabelest exécuté. Au lieu de cela, le flux d'exécution va à l'instruction immédiatement après l'instruction étiquetée. Par exemple, si j'avais une forboucle externe appelée "dustin:", alors une interruption de cela irait en fait à la première instruction exécutable suivant la fin de cette forboucle étiquetée . En d'autres termes, il agit plus comme une commande "Aller à l'instruction suivant l'instruction étiquetée".

Je ne donne aucun exemple d'utilisation de ces déclarations étiquetées breakou étiquetées continueici car il existe de nombreux bons exemples facilement accessibles en ligne. Plus précisément, les deux ressources que j'ai déjà mentionnées (instructions Java Tutorials Branching Statements et Goto Statements et Java Programming Tech Tip) incluent des exemples illustratifs simples.

Plus je travaille dans l'industrie du développement logiciel, plus je suis convaincu qu'il y a peu d'absolus dans le développement logiciel et que les positions extrémistes seront presque toujours fausses à un moment ou à un autre. En général, j'évite d'utiliser du code goto ou goto, mais il y a des moments où c'est le meilleur code pour le travail. Bien que Java n'ait pas de support goto direct, il fournit un support de type goto qui répond à la plupart de mes besoins relativement rares pour un tel support.

Cette histoire, "Java's goto" a été publiée à l'origine par JavaWorld.