Proyecto del asesor

 
Hola.
A medida que la cantidad de código crece, a veces se vuelve difícil y confuso.
He visto código de EA con un número enorme de líneas de código, me pregunto cómo se diseñan los EA complejos, ¿quizás hay algunas herramientas o trucos para tratar con algoritmos tan complejos?
 
Gregory Kovalenko:
Hola.
A medida que la cantidad de código crece, a veces se vuelve difícil y confuso.
He visto códigos de EAs con un número enorme de líneas de código, me pregunto cómo se diseñan los EAs complejos, ¿quizás hay algunas herramientas o técnicas para trabajar con algoritmos tan complejos?

¿Cuánto es demasiado? ¿Es tanto que no se puede dividir en archivos?

 
Gregory Kovalenko:
Hola.
A medida que la cantidad de código crece, a veces se vuelve difícil y confuso.
He visto código de EA con un número enorme de líneas de código, me pregunto cómo se diseñan los EA complejos, ¿quizás hay algunas herramientas o técnicas para tratar con algoritmos tan complejos?
Sí, es muy sencillo: hay que documentar con precisión cada una de las funciones y asignarlas a un archivo independiente. El archivo principal se reducirá inmediatamente y será más legible
 

Dos principios básicos:

1. Dividir el código en funciones. Una función debe ser más o menos lógicamente completa y no ser más que una pantalla para ser cubierta en un solo vistazo.

2. Reducir el número de variables globales. De las variables globales, es deseable utilizar sólo los parámetros que no cambian mientras se ejecuta el programa.

...y más:

3. programación orientada a objetos.

4. Colocar el código en varios archivos (esto complica un poco la depuración, pero tiene sentido).

 
STARIJ:
Es muy sencillo: tenemos que documentar con precisión las funciones individuales y asignarlas en un archivo separado. El archivo principal será inmediatamente más pequeño y legible

Siempre tengo un archivo mq4/mq5 y un montón de archivos mqh con clases, para cada clase un archivo separado. En general, así es como se hace en el desarrollo industrial. No hay archivos kilométricos en los que todo está mezclado.

A veces se puede ver una obra maestra en la que todo el EA está empaquetado en OnTick con las mismas piezas de código para abrir órdenes 20 veces cada una en esta fea hoja. Quiero sacar la bolsa de vómitos de inmediato ))

 
Gregory Kovalenko:
Hola.
A medida que la cantidad de código crece, a veces se vuelve difícil y confuso.
He visto código de EA con un número enorme de líneas de código, me pregunto cómo se diseñan los EA complejos, ¿quizás hay algunas herramientas o trucos para trabajar con algoritmos tan complejos?

No escriba funciones que sean siempre constantes y no cambien nunca en este estilo

void CloseOrders(int cmd)
  {
   for(int i=OrdersTotal()-1;i>=0;i--)
     {
      if(OrderSelect(i,SELECT_BY_POS))
        {
         if(OrderSymbol()==Symbol() && OrderMagicNumber()==Magic)
           {
            if(OrderType()==OP_BUY && cmd==OP_BUY)
              {
               if(!OrderClose(OrderTicket(),OrderLots(),Bid,Slippage,Blue))
                 {
                  Print("Order BUY not close! Error = ",GetLastError());
                 }
              }
            if(OrderType()==OP_SELL && cmd==OP_SELL)
              {
               if(!OrderClose(OrderTicket(),OrderLots(),Ask,Slippage,Red))
                 {
                  Print("Order SELL not close! Error = ",GetLastError());
                 }
              }
           }
        }
     }
  }

Escríbalos de forma concisa, de todas formas nadie los mira y ocupan la mitad de espacio.

void CloseOrders(int cmd) {
 for(int i=OrdersTotal()-1;i>=0;i--) {
  if(OrderSelect(i,SELECT_BY_POS)) {
   if(OrderSymbol()==Symbol() && OrderMagicNumber()==Magic) {
    if(OrderType()==OP_BUY && cmd==OP_BUY) {
     if(!OrderClose(OrderTicket(),OrderLots(),Bid,Slippage,Blue)) Print("Order BUY not close! Error = ",GetLastError());
    }
     if(OrderType()==OP_SELL && cmd==OP_SELL) {
      if(!OrderClose(OrderTicket(),OrderLots(),Ask,Slippage,Red)) Print("Order SELL not close! Error = ",GetLastError());
    }
}}}}


Comenta en el código todo el tiempo, de qué es responsable este trozo de código, no es difícil, y ahora siempre sabrás qué es el código, y reducirás el tiempo para estudiarlo

 
Vitaly Muzichenko:

No escriba funciones que sean siempre constantes y nunca cambien en este estilo

Escríbalos de forma concisa, de todas formas nadie los mira y ocupan la mitad de espacio.

Comenta en el código todo el tiempo, de qué es responsable este trozo de código, no es difícil, y ahora siempre sabrás qué es el código, y reducirás el tiempo para estudiarlo

El comentario debe ocupar la mitad del texto del programa

 
Vitaly Muzichenko:

No escriba funciones que sean siempre constantes y nunca cambien en este estilo

Escríbalos de forma concisa, de todas formas nadie los mira y ocupan la mitad de espacio.

Comentario en el código todo el tiempo, lo que esta pieza de código es responsable de, no es difícil, y aquí en la revisión siempre sabrá lo que el código, y reducir el tiempo para estudiarlo

Reorganizar los paréntesis no hace que el retraso sea menor. Antes de dar consejos, al menos eleva tu nivel a uno medio.

 
STARIJ:

El comentario debe ocupar la mitad del texto del programa

Pues bien, en ese caso el 90% del código debería contener comentarios. ¡Y necesitas todo el código sin sentido y poco legible posible para poder poner más comentarios!
 
Vasiliy Sokolov:
No, bueno, entonces el 90% del código son comentarios. Y necesitas todo el código inútil y poco legible posible, ¡para poder poner más comentarios!

Sus ideas también son dignas de mención. Deberías hablar de ellos más a menudo

 

Llevo mucho tiempo queriendo preguntar. Si en mcl5 se obtienen los datos de los indicadores de los archivos de inclusión, las clases, ¿la optimización será más rápida?

Es decir, no se llama a ningún indicador en el código del propio Asesor Experto.

Razón de la queja: