Uso del Go to

[NightShade]

Yo uso esto varias veces... porque me resuelve mucho a problemas q tengo en mis programas de newbie pero bueno... me resuelven rapido y bien... la cosa q queria pregutnar es que mucha gente me dice q porque uso el goto eso es una tecnica de programacion obsoleta... pero osea yo pregunto q tiene de malo? y nadamas me dicen q es obsoleta pero no me dan una buena razon de peso de porque no la debo usar.... ami me resuelve y no me da problemas... lo q quisiera saber es q alguien aqui si me de una buena razon de porque no lo debo usar?? y no q me diga nadamas no q es una tecnica de programacion obsoleta....

[X.Cyclop]

Iniciado por Wikipedia

La forma de programación que plantea Visual Basic ha ocasionado que muchos programadores de Visual Basic practiquen malas costumbres, entre las más comunes:

Uso de goto y etiquetas

Allí dice lo mismo y yo tampoco entiendo el porqué del "no al Goto".

[MaxExtreme]

Iniciado por X.Cyclop

Allí dice lo mismo y yo tampoco entiendo el porqué del "no al Goto".

Lo sacaste de la Wikipedia, ¿verdad? Me sonaba mucho (esa parte la hice yo ;)

Pues mira, sencillamente el goto complica un programa, es difícil depurarlo, leerlo... Y el compilador produce código peor. Compara:

Código:

int i=0;
otravez:
if(i<10) goto salir:
i++;
goto otravez:
salir:

con:

Código:

for(int i=0;i<10;i++);

[NightShade]

Es q no se, a veces veo la solucion tan sencilla con un go to.... por ejemplo en una tarea q estaba haciedno ayer... con el goto namas tuve q agregar un goto y una linea adicional y me soluciono el problema pero lo trate de hacer sin el goto y fueron como muchas lineas... weno no se... creo q simplemente no soy bueno programando :p

[X.Cyclop]

Iniciado por MaxExtreme

Lo sacaste de la Wikipedia, ¿verdad? Me sonaba mucho (esa parte la hice yo ;)

Con razón sentía que lo que decía allí era verdad.

Iniciado por MaxExtreme

for(int i=0;i<10;i++);

Eso C no lo acepta por el "int", ¿no?.

Iniciado por NightShade

creo q simplemente no soy bueno programando :p

No, que, un error lo tiene cualquiera.

[Mephisto]

Cuando tienes un programa pequeño no hay mucha complicacion en el uso del goto. El problema se presenta cuando los programas son grandes, ya que un uso del goto provoca que tu pograma sea dificil de leer y el rendimiento en cuanto a tiempo de ejecución se deteriora...

Esas son dos de las principales razones por las que se dice que no es recomendable ni una buena practica de programación usar el goto...

[X.Cyclop]

Iniciado por Mephisto

un uso del goto provoca que tu pograma sea dificil de leer
..

Aún poniendo comentarios.

[MaxExtreme]

Iniciado por X.Cyclop

Eso C no lo acepta por el "int", ¿no?.

No sabría decirte (no me sé de "pe a pa" el estándar ANSI C), pero C++ sí.

[X.Cyclop]

Iniciado por MaxExtreme

No sabría decirte (no me sé de "pe a pa" el estándar ANSI C), pero C++ sí.

Ah ok. Porque había leido algo así pero no estoy muy seguro.

[emi_ramo]

(Sé que el foro este es viejo, pero para que quede constancia... :D )

Iniciado por X.Cyclop

Eso C no lo acepta por el "int", ¿no?
Ah ok. Porque había leido algo así pero no estoy muy seguro.

C sí que acepta la declaración de variables dentro de un for, pues este abre un nuevo bloque. La estructura ampliada de este for sería esta:

Código:

(aquí i todavía no existe)

{
   int i;

   while(i < 10)
   {
       i++;
   }
}

(aquí i ya no existe)

En cuanto al uso del goto, MaxExtreme ha dado un buen ejemplo. El problema más grande es que rompe el flujo de ejecución de formas no convencionales y muchas veces tampoco lógicas. Programando, deberías ser capaz de limitarte a usar los controladores de flujo if, else if, else, switch, while, do while y for, pudiendo modificar su comportamiento con break, continue y return. Así, todos sabremos cual es la intención en cada línea del programa, incluído tú cuando ya no te acuerdes de lo que hiciste y necesites revisarlo.

Pongamos un ejemplo con el que me he topado hoy mismo:

Con goto:

Código:

int funcion(int i) {
   if(i > 0)
      goto out;

   err = func(i);

   if(err) {
      i = err;
      goto error_cancel;
   }

   err = func2(&i);

   if(err) {
      i = err;
      goto error_cancel;
   }

   if(i < 0)
      goto out_end;

out:
   return i;

error_cancel:
   printf("error\n");
   goto out;

out_end:
   printf("todo bien\n");
   goto out;
}

Sin goto (corregidme si me equivoco):

Código:

int funcion(int i) {
   if(i < 0) {
      err = func(i);
      
      if(err) {
         i = err;
         printf("error\n");
      }
      else {
         err = func2(&i);
         
         if(err) {
            i = err;
            printf("error\n");
         }
         else if(i < 0) {
            printf("todo bien\n");
         }
      }
   }
   
   return i;
}

Como podéis ver, usando una buena tabulación es posible comprender rápidamente la lógica/el flujo de la función, sin necesidad de leer, entender y reencontrar nuevas palabras, como out, out_end y error_cancel en este caso. En este caso hemos tenido suerte y nos hemos encontrado con todas las etiquetas al final de la función. Así y todo no es tan sencillo ni estándar.

También habréis notado que en el segundo caso (sin goto) he tenido que escribir dos veces printf("error"); en vez de uno como en el primer caso. En este ejemplo es una tontería y no conlleva mayores problemas. En otros casos, escribir un error puede implicar muchas líneas. En tal caso, lo recomendado sería crear una nueva función, en este caso podría ser error(), que se encargaría de aglutinar las líneas necesarias para esta tarea y que, incluso, podría admitir parámetros y dar un error personalizado, dependiendo de qué haya fallado. La creación de una nueva función podría ser ineficiente para algunos casos. En estos, sería recomendable usar una función de tipo #define:

Código:

#define error(_err_) { \
   printf("Ha ocurrido un error: %d", (_err_)); \
   (...lo que sea...) \
}

que se "compilaría" en tiempo de preprocesador, llevando el bloque del define hacia donde haya sido usado antes de que pase el compilador. Esto nos ayuda a "mantener el orden" mientras no se pierde en eficiencia.