Características del lenguaje mql4, sutilezas y técnicas - página 11

Nuevo comentario
 
Ihor Herasko:

En muchas empresas de software, un código como este haría que les arrancaran todos los dedos. Lo primero que hay que hacer siempre y en todo momento es evitar la "lectura innecesaria". Por ejemplo, si se utiliza una condición al introducir una función:

entonces se recomienda escribir:

Este enfoque ayuda mucho cuando no hay condiciones.

Una vez más, será un dolor de cabeza. Al fin y al cabo, nadie comprobó lo que devolvía la función OrderType(). ¿O tal vez devolvió -1 o 6? Este es un ejemplo de cómo se utilizan las propiedades del compilador, de las que siempre se debe prescindir. Usted mismo cita muchos ejemplos de código multiplataforma. Entonces, ¿por qué se aleja de ella en este caso? Saldrá un nuevo compilador de MQ y este código ya no funcionará correctamente.

¿Qué tienen que ver las empresas de software con lo que estamos discutiendo? El código no dejará de funcionar, no hay necesidad de cospirología aquí.

La situación es la misma con el "continue". Un código como:

es más difícil de leer que:

Y, sin embargo, la eficacia de la ejecución es la misma en ambos casos.

En este caso, el código de una línea es más fácil de leer que el de seis líneas. Además, es más lógico porque no está obligado a estar dentro de un bucle de ninguna manera. Es decir, puedes copiar y pegar el primer caso sin preocuparte del segundo.

 
fxsaber:

El ejemplo de Lots[] anterior es un tesoro de cómo el código puede ser a la vez superlacónico y totalmente comprensible.

Es usted quien encuentra el código comprensible. Pero alguien que sólo revise la documentación y vea su código se preguntará por qué el tamaño del array es 8, mientras que la documentación sólo contiene 6 tipos de orden.

Y personalmente, también me parece más fácil leer las condiciones si están separadas por separado, es decir, así:

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

También estoy más cómodo que así:

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

Pero creo que es una cuestión de gustos y costumbres. Nadie tiene que imponer ni demostrar nada.

Por otro lado, estoy de acuerdo contigo en que:

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

Y creo que es lógico, y no recuerdo ninguna otra vez.

 
Alexey Kozitsyn:

Para ti el código es comprensible. Pero alguien que acabe de mirar la documentación y vea tu código se preguntará inmediatamente por qué el array tiene tamaño 8, mientras que los tipos de orden en la documentación son sólo 6.

Así que ya ves cómo un simple código genera preguntas correctas en la mente de la gente. Y después, ¿hay que fiarse de todo lo que está escrito en la Documentación?

 
fxsaber:

Y después de eso, ¿hay que confiar en todo lo que aparece en la Documentación?

debería, es un principio básico de la programaciónRTFM

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

debería, es un principio básico de la programaciónRTFM

La realidad contradice este principio.

 
fxsaber:

¿Qué tienen que ver las empresas de software con lo que estamos discutiendo?

Bueno, ¿a quién más puedes citar como autoridad?

El código no dejará de funcionar, no hay necesidad de cospirología aquí.

Sí, en MT4 con un 99% de probabilidad lo es, porque MT4 está casi enterrado. Pero si intentas hacer una maniobra de este tipo entre plataformas, te encuentras inmediatamente con un defecto que desaparece y que conduce a un error fatal.

En este caso, el código de una línea es más fácil de leer que el de seis. Además, es más lógico porque no está ligado a la necesidad de estar dentro de un bucle de ninguna manera. Es decir, el primer caso puede copiarse fácilmente, el segundo no.

Si estamos hablando de un caso particular, puede ser cierto, porque el código dado es casi estándar para cada EA. Pero si se toma algo más complicado, es difícil leerlo cuando se escribe en una sola línea.

¿Por qué escuchar maldiciones del espacio exterior de alguien que trabaja con su código? ))

 
Ihor Herasko:

Bueno, ¿a quién más puedes citar como autoridad?

Es extraño que se toque aquí la noción de autoridad.

Sí, en MT4 hay un 99% de probabilidades de que lo sea, porque MT4 está casi enterrado. Pero si intentas hacer una maniobra de este tipo entre plataformas, te encuentras inmediatamente con un defecto que desaparece y te lleva a un error fatal.

La escritura en MT5 es idéntica.

Si hablamos de un caso particular, puede ser así porque el código dado es casi estándar para cada EA. Pero si tomas algo más complicado, es difícil leerlo cuando está escrito en una sola línea.

Y también hay construcciones if -> else if -> else. No entiendo por qué una expresión bool en un operador condicional debe darse en la forma más primitiva.

 
Alexey Kozitsyn:

Para ti el código es comprensible. Pero alguien que acabe de mirar la documentación y vea tu código se preguntará inmediatamente por qué el array es de tamaño 8, mientras que los tipos de orden en la documentación son sólo 6.

Y personalmente, también me parece más fácil leer las condiciones si están separadas por separado, es decir, así:

También estoy más cómodo que así:

Pero creo que es una cuestión de gustos y costumbres. Nadie tiene que imponer ni demostrar nada.

Por otro lado, estoy de acuerdo contigo en que:

Y creo que es lógico, y no recuerdo ninguna otra vez.

Esas son las palabras clave.

Personalmente, me molesta la ortografía de continuar en absoluto.

Para qué sirven los temas???? Si lees 

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

todo se lee en ruso:

Si se selecciona la orden y el símbolo de la orden es "nuestro" y el mago también es nuestro... entonces lo hacemos todo entre llaves.

Pero eso no suena muy ruso:

Si la orden no es seleccionada, vete a la mierda...

Si el símbolo de la orden no es nuestro, vete a la mierda...

y así sucesivamente.

¿Cuántas veces tenemos que enviarnos allí...................

Aparentemente esto tenía sentido en mql3. Era una forma de reducir el tiempo para comprobar el estado. A continuación, se comprueban todas las condiciones desde el principio hasta el final. Sin embargo, la situación se ha resuelto hace tiempo; si la comprobación encuentra una condición no cumplida, las comprobaciones posteriores se detienen. Y todos estos trucos no tienen ningún sentido.

 
Alexey Viktorov:

Estas son las palabras clave.

Personalmente, me molesta la ortografía de continuar en absoluto

Para qué sirven los temas???? Si lees

todo se lee en ruso:

Si se selecciona la orden y el símbolo de la orden es "nuestro" y el mago también es nuestro... entonces lo hacemos todo entre llaves.

Pero eso no suena muy ruso:

Si la orden no es seleccionada, vete a la mierda...

Si el símbolo de la orden no es nuestro, vete a la mierda...

y así sucesivamente.

¿Cuántas veces tenemos que enviarnos allí...................

Eso debía tener sentido en mql3. Era una forma de reducir el tiempo de comprobación de una condición. En ese momento se comprobaron todas las condiciones desde el principio hasta el final. Sin embargo, la situación se ha resuelto hace tiempo; si la comprobación ha tropezado con una condición que no se cumple, se detendrán las comprobaciones posteriores. Y todos estos trucos no tienen ningún sentido.

Tú mismo has convenido en que es una cuestión de costumbre. A mí, por ejemplo, me molesta el anidamiento innecesario, siempre lo quito con return, continue. Y en lugar de "ir al infierno" es fácil acostumbrarse a leer "se cumplen las condiciones 1 y 2":

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

Por ejemplo, me molesta el anidamiento innecesario, siempre lo elimino usando return, continue

Me irrita la"negación booleana NOT(!)", no sólo lleva un tiempo de TC, sino que la lectura de una expresión lógica se convierte en una lectura "de ida y vuelta" )))

Siempre devuelvo "true" en las funciones bool como la respuesta más esperada, como ejemplo: compruebo la disponibilidad del servidor de esta manera:

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

Lo considero bastante legible y lógico:

if(ServerDisable()) return;

si el servidor está ocupado - salida, suelo usar en las funciones comerciales, no hay necesidad de molestar al servidor con peticiones porque está ocupado

como se dice, es cuestión de gustos, pero ya se sabe: los gustos difieren ))))

1...456789101112131415161718...36
Nuevo comentario