Ir a Java

Hay un viejo chiste de programadores que dice algo como esto: Un programador enojado le dice al segundo programador: "¡Vete al infierno!" El segundo programador responde con obvia repulsión: "¡Uf, usaste goto!" El punto de este humor nerd es que para muchos programadores, el uso de "goto" es la peor ofensa que uno puede cometer.

Hay varias razones por las que el goto tiene tan poca estima entre los desarrolladores de software. El artículo de Edsger W. Dijkstra Un caso en contra de la declaración GO TO es un tratado relativamente temprano sobre los males del abuso de GOTO. En ese artículo, Dijkstra afirma: "[Me convencí] de que la declaración go to debería eliminarse de todos los lenguajes de programación de 'nivel superior'". La carta Ir a la declaración considerada perjudicial de Dijkstra no solo criticó la declaración goto, sino que también inició una popular tendencia en informática de usar la frase "considerado dañino" (aunque esas dos palabras aparentemente se usaron fuera de la programación antes de eso).

Muchos programadores desde Dijkstra se han visto afectados por algunos de los problemas de mantenibilidad asociados con el uso de sentencias goto en ciertos lenguajes. Otros programadores han escuchado estas historias o les han golpeado tanto el "No usarás goto" que no necesitan experimentar sus inconvenientes de primera mano para creer que no deberían usar GOTO.

Aunque la declaración goto parece tener una mala reputación en general, no deja de tener sus partidarios. Frank Rubin escribió una respuesta a la declaración Ir a de Dijkstra considerada perjudicial(Marzo de 1968) llamado GOTO Considered Dañino 'Considerado Dañino (marzo de 1987). En esa carta, Rubin escribió sobre la carta de Dijkstra que tuvo un efecto tan dramático en los programadores que "la noción de que el GOT0 es dañino es aceptada casi universalmente, sin cuestionar ni dudar". De esta observación, Rubin escribió: "Esto ha causado un daño incalculable al campo de la programación, que ha perdido una herramienta eficaz. Es como los carniceros que prohíben los cuchillos porque los trabajadores a veces se cortan". Tenga en cuenta que Dijkstra respondió a la carta de Rubin con Sobre una correspondencia algo decepcionante. La página Go To de Cunningham & Cunningham Wiki dice lo siguiente sobre la declaración goto: "El aprendiz lo usa sin pensar. El oficial lo evita sin pensar. El maestro lo usa pensativamente".

Hay muchos otros recursos que cubren los pros y los contras de usar la instrucción goto. No pretendo repetir ese debate aquí más que la breve presentación de la historia temprana de la controversia ya cubierta. He escuchado a algunos desarrolladores de Java decir que Java no tiene una declaración goto y eso es lo que quiero discutir en el resto de esta publicación de blog.

Java reserva "goto" como palabra clave reservada. Sin embargo, es una palabra clave no utilizada. Lo que esto significa es que, aunque la palabra clave en realidad no hace nada productivo, también es una palabra que no se puede usar en el código para nombres de variables u otras construcciones. Por ejemplo, el siguiente código no se compilará:

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 intento compilar ese código, veo un error como el que se muestra en la siguiente captura de pantalla.

El mensaje de error "esperado" con un puntero en el espacio antes de "goto" le da a un desarrollador Java experimentado una pista suficiente para darse cuenta rápidamente de que hay algo mal en el uso de "goto". Sin embargo, puede que no sea tan obvio para alguien nuevo en Java.

Generalmente no uso la construcción goto, pero también reconozco que hay situaciones en las que su uso hace que el código sea más legible y use soluciones menos locas que no usarlo. En Java, esto también se ha realizado y se proporciona soporte para algunas de las situaciones más comunes en las que una declaración goto sería más útil y probablemente sería preferible a las alternativas. Los ejemplos más obvios de esto son las declaraciones etiquetadas breaky etiquetadas continue. Estos se analizan y demuestran en la sección de tutoriales de Java Sentencias de ramificación.

La capacidad de etiquetar una declaración en particular y luego aplicar breako continueaplicar a esa declaración en lugar de su declaración más inmediata (como no etiquetada breako lo continuehace) es especialmente útil en los casos en que los bucles anidados requerirían más código y un código más complejo para lograr lo mismo. cosa. He descubierto que a menudo puedo rediseñar mis estructuras de datos y código para evitar tales situaciones, pero esto no siempre es práctico.

Otro buen recurso relacionado con el uso de la funcionalidad goto-like en Java es el 13 de junio de 2000 JDC Tech Tip Goto Statements and Java Programming. Como señala este consejo, las etiquetas se pueden usar en cualquier bloque y no se limitan a breaky continue. Sin embargo, es mi experiencia que la necesidad de este enfoque fuera de breaky continuees mucho menos común.

Una observación importante sobre las etiquetas es que la ejecución del código no regresa literalmente a esa etiqueta cuando break somelabelse ejecuta. En cambio, el flujo de ejecución va a la instrucción que sigue inmediatamente a la instrucción etiquetada. Por ejemplo, si tuviera un forbucle externo llamado "dustin:", entonces un salto a eso iría a la primera declaración ejecutable que sigue al final de ese forbucle etiquetado . En otras palabras, actúa más como un comando "ir a la instrucción que sigue a la instrucción etiquetada".

No proporciono ningún ejemplo del uso de estas declaraciones etiquetadas breako etiquetadas continueaquí porque hay muchos buenos ejemplos que se encuentran fácilmente en línea. Específicamente, los dos recursos que ya he mencionado (tutoriales de Java enunciados de ramificación y enunciados Goto y Consejo técnico de programación de Java) incluyen ejemplos ilustrativos simples.

Cuanto más trabajo en la industria del desarrollo de software, más me convenzo de que hay pocos absolutos en el desarrollo de software y que las posiciones extremistas casi siempre estarán equivocadas en un momento u otro. Generalmente evito el uso de código goto o similar a goto, pero hay ocasiones en las que es el mejor código para el trabajo. Aunque Java no tiene soporte de goto directo, proporciona un soporte de tipo goto que satisface la mayoría de mis necesidades relativamente poco frecuentes de dicho soporte.

Esta historia, "Java's goto" fue publicada originalmente por JavaWorld.