Por qué valenok2003 está en contra de MT5 - página 2

 
Zhunko:

¡О! ¡Esto es goto otra vez! Me encanta. Puedes prescindir de él. Siempre se puede, pero no es necesario.

En algunos casos, goto permite simplificar el código y acelerarlo. Leí en algún artículo que los conductores se escriben con él para acelerar las transiciones.


Hola.

El código del ensamblador no conoce otro camino.

 
IgorM:

Simplificar el código es improbable, hacerlo ilegible para otros es seguro, sobre la velocidad - depende de qué tareas, y quién tiene qué "escritura al programar", en principio, no quiero ni discutir, parece que discutimos seriamente sobre los beneficios y perjuicios de goto http://www.gamedev.ru/flame/forum/?id=69459.

Si se llega al nivel de desensamblaje del programa, lo más probable es que los bucles en todos los JVS estén organizados como transiciones condicionales jcxz y demás..,

que será esencialmente una construcción if(cx==0) goto label

Para la salida anticipada de bucles anidados, para saltar de diferentes condiciones a un solo punto? Esto simplifica el código. Lo uso muy a menudo. A veces lo uso para hacer bucles.

sargazo:

Hola.

El código del ensamblador no conoce otro camino.


No estamos hablando de ensamblador :-)
 
Zhunko: Para la salida anticipada de bucles anidados, para pasar de diferentes condiciones al mismo punto? Simplifica el código. Lo uso mucho. A veces lo utilizo para los bucles.

Si es así, es así :), como dice el refrán: "¡todos los colores del rotulador son diferentes!" ))))))))

El asunto es individual, ya ves, al desarrollador principal le molesta la POO. Si no usara la POO, hace tiempo que estaría surcando el Gran Teatro MQL5.

 

http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd215.html

За многие годы я утвердился во мнении о том, что квалификация программистов - функция, обратно зависящая от частоты появления операторов go to в их программах.

...deberíamos hacer... todo lo que podamos para salvar la distancia conceptual entre un programa estático y un proceso dinámico, para que la correspondencia entre el programa (que se desarrolla en el espacio del texto) y el proceso (que se desarrolla en el tiempo) sea lo más evidente posible.

 

Esta es sólo una de las muchas opiniones. Hay tantos a favor como en contra. Es una cuestión de gusto y estilo.

El autor se limita mucho.

 
Edsger W. Dijkstra es uno de esos hombres cuyo nombre se asocia a la transformación de la programación del chamanismo a la ciencia(*).
 
Es, por supuesto, muy limitado - un ganador del Premio Turing
 
Zhunko:

Esta es sólo una de las muchas opiniones. Hay tantos a favor como en contra. Es una cuestión de gusto y estilo.

El autor se limita mucho.


La tendencia moderna de la programación es tal que los programas suelen estar escritos y acompañados por equipos de programadores. Esto impone requisitos sobre la calidad del código, su legibilidad.

Mi opinión: el código debe ser claro y estar bien comentado. De nuevo mi opinión personal: go to es un operador perjudicial, impide leer el código. Imagínese un programa de al menos 500 líneas, con un centenar de etiquetas y saltos hacia ellas.

 

La cuestión de la aplicación del goto está en el ámbito de las preferencias personales. No le gusta y se inventa una razón por la que no le gusta.

Hay otros a los que les gusta y se les ocurre una razón por la que les gusta. Para mí, todas estas razones son las mismas. Mi código se simplifica cuando se aplica goto, entonces lo uso, si no, no lo uso.

No me limito a las especulaciones de los demás.

sand:


Imagina un programa de al menos 500 líneas, con un centenar de etiquetas y transiciones a ellas.

Los controladores se siguen escribiendo así. ¿Por qué?
 
Zhunko:

Los controladores se siguen escribiendo así. ¿Por qué?


Porque la velocidad de ejecución es lo primero, lo segundo y lo tercero en los conductores.

¿Por qué necesitamos lenguajes de alto nivel si podemos escribir todo en lenguaje ensamblador?

¿Y por qué no ponen boomboxes y asientos convertibles en la Fórmula 1?