Todo esto es muy técnico a veces, y puede parecer purismo, pero tengamos un par de cosas en cuenta.
"Goto" es una sentencia muy antigua, y proviene de lenguajes interpretados con Basic.
Incluso en lenguajes interpretados, se puede programar de forma eficiente sin algo tan contrario a la claridad como es un salto incondicional, pero en algunos interpretes muy antiguos, cabe la posibilidad de que tuviera algún sentido (poco), desde el momento en que el lenguaje interpretado va leyendo secuencialmente una lista de instrucciones.
En lenguajes compilados, usar "goto", funciones, acciones o cualquier otra estructura no va a influir en su velocidad de ejecución, porque el compilador "ya se las apaña" para desmenuzar tu código y convertirlo en "otra cosa". En lenguaje máquina si que existen obviamente los saltos incondicionales (ahí son algo diferente). Tu código en realidad solo va a ser mas eficiente y rápido mediante la elección de los tipos de variables adecuadas, la resolución mas eficiente de un algoritmo y otras, entre las cuales pueden estar (por ejemplo) que compiles específicamente para un tipo determinado de procesador y otras.
Pero, que pongas mas o menos comentarios, que definas las funciones delante o detrás del main, que uses variables globales o locales exclusivamente y otras no van a hacer que tu programa "corra mas".
Dado que tu programa en principio, puede ser igual de eficiente si usas goto que si no lo usas, ¿porque esa manía y odio furibundo hacia esa instrucción?
Por una razón muy simple. Tu código no siempre es "definitivo". Cuando se crea una aplicación grande "seria", digamos que dedicas 3 meses a completarla. ¿Ya has terminado?
No, claro que no, esa aplicación probablemente requiera retoques en el futuro, ampliaciones, corregir potenciales errores que se te hayan colado, incluir nuevas características, etc.
E incluso es posible que quien haga esas modificaciones no seas tu, sino otra persona, y que a ti te toque modificar el código de otra persona.
Y aquí es donde se justifican esas cosas. Tu trabajarás siempre sobre ese código fuente. Si esta estructurado, es claro, documentado correctamente y sigue una serie de convenciones, tu trabajo será infinitamente mas sencillo y rápido. Si el código es confuso, con saltos incondicionales a punta pala, mal documentado (o sin comentarios), aunque el programa sea rápido, eficiente y haga lo que se espera de el, modificarlo será mucho mas difícil.
Es la diferencia entre trastear con un código claro, organizado y debídamente documentado, y trabajar con un código que no lo está. En un caso es fácil, en el otro no lo es en absoluto.
Y la verdad, las personas rara vez se acuerdan perfectamente de como funciona un código que hicieron hace meses, o años incluso.
Vamos, es como si tienes que revisar un libro, y este libro está bien organizado, tiene su indice general, indice de materias, etc... y sigue un orden lógico. El otro libro tiene las páginas al azar, con señales que indican a donde debes de saltar a cada momento, no tiene índice y además está escrito de forma poco clara.
Y no hay mas misterio
"Goto" es una sentencia muy antigua, y proviene de lenguajes interpretados con Basic.
Incluso en lenguajes interpretados, se puede programar de forma eficiente sin algo tan contrario a la claridad como es un salto incondicional, pero en algunos interpretes muy antiguos, cabe la posibilidad de que tuviera algún sentido (poco), desde el momento en que el lenguaje interpretado va leyendo secuencialmente una lista de instrucciones.
En lenguajes compilados, usar "goto", funciones, acciones o cualquier otra estructura no va a influir en su velocidad de ejecución, porque el compilador "ya se las apaña" para desmenuzar tu código y convertirlo en "otra cosa". En lenguaje máquina si que existen obviamente los saltos incondicionales (ahí son algo diferente). Tu código en realidad solo va a ser mas eficiente y rápido mediante la elección de los tipos de variables adecuadas, la resolución mas eficiente de un algoritmo y otras, entre las cuales pueden estar (por ejemplo) que compiles específicamente para un tipo determinado de procesador y otras.
Pero, que pongas mas o menos comentarios, que definas las funciones delante o detrás del main, que uses variables globales o locales exclusivamente y otras no van a hacer que tu programa "corra mas".
Dado que tu programa en principio, puede ser igual de eficiente si usas goto que si no lo usas, ¿porque esa manía y odio furibundo hacia esa instrucción?
Por una razón muy simple. Tu código no siempre es "definitivo". Cuando se crea una aplicación grande "seria", digamos que dedicas 3 meses a completarla. ¿Ya has terminado?
No, claro que no, esa aplicación probablemente requiera retoques en el futuro, ampliaciones, corregir potenciales errores que se te hayan colado, incluir nuevas características, etc.
E incluso es posible que quien haga esas modificaciones no seas tu, sino otra persona, y que a ti te toque modificar el código de otra persona.
Y aquí es donde se justifican esas cosas. Tu trabajarás siempre sobre ese código fuente. Si esta estructurado, es claro, documentado correctamente y sigue una serie de convenciones, tu trabajo será infinitamente mas sencillo y rápido. Si el código es confuso, con saltos incondicionales a punta pala, mal documentado (o sin comentarios), aunque el programa sea rápido, eficiente y haga lo que se espera de el, modificarlo será mucho mas difícil.
Es la diferencia entre trastear con un código claro, organizado y debídamente documentado, y trabajar con un código que no lo está. En un caso es fácil, en el otro no lo es en absoluto.
Y la verdad, las personas rara vez se acuerdan perfectamente de como funciona un código que hicieron hace meses, o años incluso.
Vamos, es como si tienes que revisar un libro, y este libro está bien organizado, tiene su indice general, indice de materias, etc... y sigue un orden lógico. El otro libro tiene las páginas al azar, con señales que indican a donde debes de saltar a cada momento, no tiene índice y además está escrito de forma poco clara.
Y no hay mas misterio