To GOTO or to not GOTO. That’s a good question!
Escrito por Luix hace 1 años
bajo una licencia de Creative Commons
1135 visitas. Etiquetas: codigo, to, programacion, goto, go
Recientemente asistí a un debate en un foro de esta web sobre el uso de GOTO en programación, un tema muy controvertido aun en estos días de paradigmas de computación avanzados como la Orientación al Objeto, Eventos y demás entes peculiares. Se trataba de un caso concreto en el que se planteaba una liberación de recursos de la máquina en la cual se ejecutaba un programa en lenguaje C. A raíz de los interesantes comentarios y discusiones que surgieron, he decidido abrir un pequeño artículo sobre el tema, cuya fuente fundamental es Steve McConnell y su libro Code Complete 2. Un saludo a Fran, ya que la idea del artículo surgió gracias a su hilo ;-).
Por qué no usar GOTO
Empecemos por los inconvenientes por dos razones: la primera es que el autor lo hace así en su libro, y la segunda es que me parece del todo apropiado ya que a cualquier programador que le preguntes sobre el asunto dirá, a bote pronto: ¡no a los GOTO!
- Según Dijkstra (uno de los padres de la computación moderna, por si algún despistado no sabe quién es), el uso de GOTO nos lleva irremediablemente a una peor calidad en el código, y una mayor dificultad en probar la correctitud del mismo.
- Indentación rota en el código, por su estilo. Es difícil estructurar de forma legible el código al utilizar GOTO. Al dificultar la legibilidad empeora, además, el mantenimiento del código.
- Romple las optimizaciones del compilador, al forzar los caminos a seguir.
- Es falso que el código con GOTO sea más pequeño o más rápido. Depende de cómo traduzca el compilador el código a lenguaje máquina, lo cual es desconocido para la mayoría de los mortales… Steve McConnell dedica un par de capítulos enteros en Code Complete 2 al “code tuning” y romper mitos sobre qué es más rápido y qué no: la conclusión es que si no se miden tiempos es una insensatez afirmar que un código es más rápido que otro.
- En la práctica, GOTO rompe el principio de que el código debería fluir de arriba hacia abajo. Incluso aunque al principio se usen cuidadosamente, al final se reproducen como termitas en una casa podrida.
Para acabar nuestros argumentos en contra del uso de GOTO, simplemente comentar que después de dos décadas parece que Dijkstra sigue teniendo razón y por eso muchos lenguajes de programación modernos no implementan el uso de GOTO. Una cita interesante:
Las etiquetas GOTO deberían ir alinadas a la izquierda con todas las letras en mayúsculas, y deberían incluir el nombre del programador, el número de teléfono de su domicilio y su número de la tarjeta de crédito bancaria.
(Abdul Nizar)
Por qué sí usar GOTO
Malas noticias para los que llegaron hasta aquí pensando que tenían la solución a todos sus problemas: hay situaciones en las cuales el uso de GOTO es, digamos, aceptable (no me voy a atrever a decir recomendable).
- Si se usa cuidadosamente puede aportar ventajas. Muchos inconvenientes del uso de GOTO vienen por el uso indiscriminado de esta construcción.
- Puede eliminar duplicaciones de código. Las duplicaciones son problemáticas cuando sólo se modifica una de las copias. Además, el tamaño del ejecutable es así menor en espacio.
- Útil en operaciones que reservan recursos, hacen uso de esos recursos y después los liberan. Permite tener todo en un sitio y que no se olvide liberar alguno. Una buena alternativa a esta solución serían los bloques try-catch, siempre que el lenguaje de programación implemente tales construcciones.
- En algunos casos puede producir código más pequeño, más rápido.
- Centrarse en la descomposición, ese es el objetivo, no evitar GOTO. Soluciona el problema con la mejor herramienta disponible.
- Hay lenguajes modernos que incluyen GOTO: Visual Basic, C++, Ada.
Para terminar los argumentos a favor, señalamos que hay gente (Sheil) que no sostiene o dicho por Dijkstra y Schneiderman, aunque tampoco afirman que sea bueno utilizar GOTO indiscriminadamente.
Conclusiones
Por lo general no es bueno utilizar GOTO, salvo en aquellos casos en los que las ventajas sean cuantiosas. Los libros de texto habituales no ayudan porque siempre ponen ejemplos burdos y sencillos en los cuales salta a la vista que no debe utilizarse GOTO. Alternativas a GOTO son: if anidados, variables de estado y bloques try-catch.
En la mayoría de los lenguajes modernos, el 90% de los usos de GOTO pueden ser sustituídos perfectamente por otra cosa. Si aun así se decide optar por utilizar GOTO, es indispensable documentar tal uso en el código.
——————————————————————————
Fuente:
Code Complete 2, Steve McConnell
Actualizado: Fé de erratas
Ya que nadie me lo dice, y que no se me permite cambiar el título del artículo, señalar que el título correcto debería ser To GOTO or not to GOTO y no To GOTO or to not GOTO, si al menos pretendía parafrasear a Shakespheare (nada menos) y su archiconocido to be or not to be.
Más información:
http://luixrodriguezneches.wordpress.com
Artículos Relacionados
- Autentificación Web usando Interceptor de Struts 2
- Comentando el código
- Comentando las limitaciones del código
- [Lua] Detalles de sintaxis
- [D] Introducción a D
Grupos relacionados
Ingeniero Informático por la Universidad de Valladolid (España). Me interesa la programación, gestión de proyectos, patrones, metodologías..., la seguridad y la administración de redes y sistemas operativos. Actualmente trabajo en Códice Software, una empresa vallisoletana que desarrolla PlasticSCM, una herramienta de control de versiones, además de consultoría a clientes sobre temas relacionados con la Gestión de Configuraciones. http://luixrodriguezneches.wordpress.com
9 comentarios en "To GOTO or to not GOTO. That’s a good question!"
nestor.salceda escribió
hace 1 años
Fran escribió
hace 1 años
Bien explicado, yo ya di mi opinión el hilo del foro, así que no tengo nada más que decir.
ocell escribió
hace 1 años
Muy bien por el resumen. En mi opinión, si programas con lenguajes de alto nivel, a no ser que sea totalmente necesario y vital, no debería utilizarse. Pero en la practica siempre se acaba utilizando en algún momento una instrucción (llámese goto, break un return mal puesto, etc.) que rompe la ejecución secuencial del código.
Luix escribió
hace 1 años
Bueno, sobre los break y los continue tengo que puntualizar una cosa: están mejor vistos que los goto. Y los return bien utilizados son muy útiles, para señalar de forma muy explícita dónde tiene que acabar una rutina.
badprogrammer escribió
hace 1 años
La realidad es que las razones a favor de GOTO no son nada claras, espero que estén más elaboradas en el libro!
Dijkstra es un referente de gran importancia en el mundo del software pero no hay que olvidar que era un poco "talibán" con esos comentarios del tipo: Si aprendes a programar con X lenguaje, nunca serás un buen programador.
Un autor que era muy famoso cuando empecé yo en esto del internet era W. Richard Stevens. Mayormente famoso por su Unix Network Programming o los tres volumenes del TCP/IP Illustrated. Cuando alguien le preguntó por qué usa gotos en su codigo el respondió esto:
Read Structured Programming with go to Statements by Knuth in the ACM Computing Surveys, Vol. 6, No. 4, Dec. 1974 issue. (In fact, this entire issue of Computing Surveys is a classic.) My challenge to the goto-less programmer is to recode tcp_input() (Chapters 27 and 28 of TCP/IPIv2) without any gotos ... without any loss of efficiency (there has to be a catch).
Desde luego, hace mucho tiempo de eso. Pero también de Dijkstra!
badprogrammer escribió
hace 1 años
Os paso un enlace interesante sobre el tema referente al kernel de linux:
http://209.85.129.132/search?q=cache:fhTIYijOIJwJ:kerneltrap.org/node/553+kernel+trap+http://kerneltrap.org/node/553&hl=es&ct=clnk&cd=1&gl=es
La actitud de Linus, como siempre, bastante tajante. Pero se dan buenas ideas de usos adecuados del goto, como el que comentaba Fran que sin duda es mucho mejor que una función con punteros como decían por ahí :-)
Indigo escribió
hace 1 años
Llevo bastante tiempo si aparecer por aquí (es lo que tienen las prisas en los desarrollos)... Leyendo esto me he recordado de este post que hablaba un poco del tema http://geeks.ms/blogs/rfog/archive/2008/10/17/no-uses-goto-que-yo-lo-usar-233.aspx
En un comentario comentan el libro que te estás leyendo, que por cierto, debería leermelo yo también. Lo tengo en la estantería desde hace tiempo, y no le he dedicado demasiado tiempo.
gaston escribió
hace 1 años
El goto manipula bruscamente la ejecución, brindando saltos no es cierto?
Si no usamos goto, no deberiamos usar break o continue, pero estos ultimos son necesarios y bien vistos.
El código queda mucho mas elegante sin goto, pero un goto usado sabiamente puede hacer que un código sea mucho mas elegante.
Depende de cada uno usarlo o no, en mi caso hace años que no lo uso.
Saludos.
Luix escribió
hace 1 años
Un break o un continue no son lo mismo que un goto, aunque su filosofía es la misma que la del goto. El problema fundamental del goto es la legibilidad del código, su mantenibilidad por tanto, y los errores que puede provocar.
Un break o un continue son más legibles y menos propensos a errores.
© Copyright 2008-2009 debug_mode=ON | Aviso legal | Contacto | FAQ | ¿Quiénes somos?
|
#1
Buena recopilación del Code !! :D
La verdad es que el hombre tiene un punto de mira bastante pragmático :)
Un saludo !