¿Por qué es no recomendable el uso de "goto"?

[Foxy Rider]

Si van a decir cosas como "Dicen que" y similares repitiendo demás crap, por favor, pongan argumentos justificados, nada de exageraciones, código or GTFO.

Por que la demonización de goto tarde o temprano tiene que terminar.
Es una herramienta como cualquier otra, y como *CUALQUIER* construcción en un lenguaje de programación no debe ser abusada y debe utilizarse donde sea más coherente, pero muchos usan la exageración (léase: abuso del goto y ponerlo all over the place) como una forma de desaconsejar su uso.

Bajo esa idea, podríamos decir que cosas como punteros o cualquier otra construcción es "desaconsejable"
Los argumentos contra el goto fueron desarmados hace mil años, pero hay gente que insiste repetir cosas de 1968 ...

Saludos.

P.S: sí, este es un mensaje al buen estilo "leave goto alone" (o era leave britney alone ? méh)
P.S 2 : me toca un poco los ... que yo diga que hay gente repitiendo crap (y explique un poquito por qué y ofrezca referencias) , y vengan a hacer eso sin aportar absolutamente nada a la justificación de eso.

[Akai]

Oh, Se me pasó complementar el comentario acerca de la charla que cité anteriormente y no voy a editar un post si alguien ha respondido ya después de publicarlo.

Uno de los ejemplos sobre los cuales en el kernel de linux se usa bastante el goto sería una estructura similar:

Código (c) [Seleccionar] Expandir


pthread_mutex_lock(&m)
if (lo_que_sea){
    haz_cosas();
}else{
    //no queremos continuar, pero aun asi tenemos que desbloquear
    goto exit;
}
//aqui se tendria mucho mas codigo
...

exit:
pthread_mutex_unlock(&m);
return algo;


Obviamente, con un lock no parece mucho cambio duplicar el código. Pongamos 15 locks.

En situaciones como estas donde en unos casos la función debería terminar y se han bloqueado diversos locks y que es muy probable que dicho código se vaya a modificar, creo que queda claro que es preferible no duplicarlo en el else sino hacer un goto al final de la función, camino que también se recorrería si la función entrase en el if, haciendo a parte más cosas.

Sea cual sea el caso, al finalizar la función tenemos que soltar esos locks, llegaremos bien sea con un salto directo o bien por el recorrido completo. En este caso creo que se ve que el goto simplifica el código.

saltos para atrás son los que en determinados casos pueden marear la perdiz (aun así, qué son los bucles sino saltos condicionales hacia atrás?), hacia adelante no tienen ningún problema como creo que se puede ver en este ejemplo.

[leogtz]

Como dato interesante, ¿saben cuántos goto's hay en el código fuente de Perl?

Código [Seleccionar] Expandir

─[0 leo@leo-945GCT-M ~/Descargas/perl-5.14.1]$
└─> find . -type f -iregex ".*c$" -exec cat {} \; | grep -i "goto" | wc -l
1430
┌─[0 leo@leo-945GCT-M ~/Descargas/perl-5.14.1]$
└─>


Perl está hecho totalmente en C y que yo sepa no tiene bugs.

[Littlehorse]

No siempre menos lineas de código significa que este bien hecho y el goto para lo único que sirve en el 99% de los casos es para ahorrar lineas de código, esa por lo menos es mi opinión.

Que se use en Perl o en el Kernel que gusten no es una muestra de nada puesto que son programadores como todos; no puede tomarse eso como una referencia de que algo es correcto. Con el mismo criterio podemos decir que Dijkstra comento que no debería usarse y explico muy bien por que, y ¿Quien de ustedes se atreveria a decir que Dijkstra no tenia idea de lo que hablaba?.
Como verán ninguna de estas referencias pueden tomarse para probar que "esto es así sin ninguna duda" porque cada uno tiene una visión distinta; se puede estar de acuerdo o no.

Personalmente no creo que goto sea adecuado para nada, genera confusión en el código y torna al flujo del algoritmo difícil de seguir para los que deban continuar lo que uno hizo (nada mas propenso a errores que un programador que no puede entender el código base con el cual debe trabajar).

Lo del goto exit; puede aparentar valido cuando se muestra en 5 lineas pero cuando comienzan los errores, las excepciones, cuando comienza las unidades de testeo y la depuración, la historia es otra.

Estoy de acuerdo con lo que dijo Zero, es cuestión de gustos.

Saludos!

PD: Sin comentarios como gtfo ni demás porque todos tienen derecho a opinar en la forma que gusten mientras no se falte el respeto a nadie.

[leogtz]

No siempre menos lineas de código significa que este bien hecho y el goto para lo único que sirve en el 99% de los casos es para ahorrar lineas de código, esa por lo menos es mi opinión.

Que se use en Perl o en el Kernel que gusten no es una muestra de nada puesto que son programadores como todos; no puede tomarse eso como una referencia de que algo es correcto. Con el mismo criterio podemos decir que Dijkstra comento que no debería usarse y explico muy bien por que, y ¿Quien de ustedes se atreveria a decir que Dijkstra no tenia idea de lo que hablaba?.
Como verán ninguna de estas referencias pueden tomarse para probar que "esto es así sin ninguna duda" porque cada uno tiene una visión distinta; se puede estar de acuerdo o no.

Personalmente no creo que goto sea adecuado para nada, genera confusión en el código y torna al flujo del algoritmo difícil de seguir para los que deban continuar lo que uno hizo (nada mas propenso a errores que un programador que no puede entender el código base con el cual debe trabajar).

Lo del goto exit; puede aparentar valido cuando se muestra en 5 lineas pero cuando comienzan los errores, las excepciones, cuando comienza las unidades de testeo y la depuración, la historia es otra.

Estoy de acuerdo con lo que dijo Zero, es cuestión de gustos.

Saludos!

PD: Sin comentarios como gtfo ni demás porque todos tienen derecho a opinar en la forma que gusten mientras no se falte el respeto a nadie.

Sí, programadores, pero programadores muy brillantes, y si ellos usan goto es por algo, para algo les servirá, y por algo no lo hicieron de otra manera, ¿no crees?.

[Littlehorse]

Lo de programadores muy brillantes es relativo, por supuesto algunas personalidades conocidas lo son, algunos desconocidos también lo serán, eso no significa que todos lo sean. Pero igualmente eso no importa mucho, a lo largo de la vida en sistemas puedes encontrarte con muchas personas brillantes y con muchas eminencias en determinadas áreas, así y todo no se puede dar por sentado todo lo que digan y/o hagan por mas geniales que sean como profesionales.

Muchas personalidades conocidas que son brillantes en lo que hacen opinan que C++ es una basura mientras que otros opinan que C++ es una maravilla; ese es uno de los tantos debates interminables.

Una frase muy cierta del libro "Spring in Action" que leí hace un tiempo que ejemplifica un poco todo esto:

There are certain things that most people can agree upon: The fact that the sky
is blue, that Michael Jordan is the greatest player to touch a basketball, and
that Star Trek V should have never happened. And then there are those things that
stir up controversy, such as politics, religion, and the eternal "tastes great/less
filling" debates.

Como profesional tienes que analizar las visiones existentes y ver cual te convence mas y luego de eso verificar que tan cierta es esa visión que tanto te convence. De lo contrario terminarías usando un framework solo porque tal persona brillante lo usa, terminaras comprando un auto porque tal persona lo usa, y así puedo seguir con interminables ejemplos que lograrían que tomes muy malas decisiones en la vida así sea en lo profesional como en lo personal.

Saludos

[leogtz]

A lo que voy es que si hay evidencia de que el correcto uso de esa sentencia da resultados, no entiendo porque no usarla. El goto lo usé durante mucho tiempo y creanme que jamás tuve problemas de nada, como programador se está consciente de los saltos que se hacen.

[Littlehorse]

El programador puede ser, pero tus compañeros de trabajo? usualmente no trabajas solo, y no siempre vas a ser vos el que depure el código. Incluso luego de 6 meses, vos no vas a ser el mismo que codifico esos gotos, y ni los comentarios van a ayudarte lo suficiente.

Obviamente no vas a tener problemas con goto en proyectos chicos, pero en aplicaciones reales los tenes, por esa misma razón es una característica de lenguaje obsoleta. No porque a alguien se le ocurrió demonizarla, no por cuestiones religiosas si no por simples conceptos de diseño de software que ya están muy bien explicados.

Habría que analizar la evidencia porque en lo que a mi respecta que se utilice en X lugar para mi no significa nada y eso es lo único que se ha dicho hasta ahora. Que en un link Linus diga que Dijkstra no tenia idea de lo que hablaba y que goto en algunos casos sirve para mi tampoco significa nada.

Habra algunos casos en donde usar goto es valido? seguro! de ahí a que haya varios casos en donde sea la mejor opción hay un abismo puesto que porque alguien considere que para algún caso en particular, goto es la mejor opción, no lo hace verdad, solo lo hace una opinión.

De hecho, de "Linux Device Drivers, 2nd Edition" -se encuentra dentro de unos de los links que pusieron- claramente se puede leer esto:

Error recovery is sometimes best handled with the goto statement. We normally hate to use goto, but in our opinion this is one situation (well, the only situation) where it is useful. In the kernel, goto is often used as shown here to deal with errors.

The following sample code (using fictitious registration and unregistration functions) behaves correctly if initialization fails at any point.

 

Código (c) [Seleccionar] Expandir

   int init_module(void)
     {
     int err;

      /* registration takes a pointer and a name */
      err = register_this(ptr1, "skull");
      if (err) goto fail_this;
      err = register_that(ptr2, "skull");
      if (err) goto fail_that;
      err = register_those(ptr3, "skull");
      if (err) goto fail_those;

      return 0; /* success */

      fail_those: unregister_that(ptr2, "skull");
      fail_that: unregister_this(ptr1, "skull");
      fail_this: return err; /* propagate the error */
     }

Los problemas que Dijkstra menciono respecto de usar goto siguen siendo validos, no seria ni el primero ni el ultimo en exponer posibles problemas que permanecen vigentes en el tiempo incluso luego de décadas. Se le suele llamar "estar adelantado a la época" y Dijkstra era claramente uno de esos afortunados.

Lo único que puedo decir es repetir lo que ya dije en un pm; si quieren usarlo porque para determinado caso les parece correcto, haganlo, como profesional y moderador es mi deber avisarles que en el 99% de sus actuales/futuros trabajos a sus referentes técnicos no va a gustarles.

Saludos!

[Meta]

En clases de programación, el profesor nos prohibió usar goto, excepto en ASM.

[dandy_hack]

y si yo lo uso en batch es bueno usarlo o no es muy recomendable???