Proyecto del asesor - página 2

Nuevo comentario
 
Vasiliy Sokolov:

Reacomodar los paréntesis no hace que sea menos desordenado. Antes de dar consejos, al menos sube tu nivel a la media.

¿Qué pasa con mi nivel?

 
STARIJ:

El comentario debe ocupar la mitad del texto del programa

Incluso escribo algunas cosas - primero un largo comentario "lo que debería pasar aquí", y luego el código que lo implementa :-) Por cierto, yo también aconsejo este enfoque para los novatos
 
Maxim Kuznetsov:
Algunas cosas que escribo - primero un largo comentario "lo que debería estar allí", y luego el código que lo implementa :-) Por cierto, aconsejo este enfoque para los novatos, también
Primero un stub para la función con la descripción de lo que hará y el return(algo). Entonces el código
 
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


Vitaly, lo he entendido bien, ¿tienes una pantalla de portátil de 12"?

Recuerdo que en los viejos tiempos, en el CV-1420 con pantalla alfanumérica 24 líneas x 80 caracteres, también, trató de ahorrar espacio )) Ahora, de alguna manera, trato de escribirlo para que sea más rápido de entender.

 
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.


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

Y luego capta con tus ojos a qué se refieren estos 4 paréntesis de la parte inferior. Este es un estilo de código muy malo. En general MS tiene lo mejor, y el hecho de que MQ profese el estilo K&R no es razón para emularlo. Los tiempos de las tarjetas perforadas y los monitores de 80x24 ya han pasado.

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());
    }
}}}}
Vasiliy Sokolov:
Bueno, entonces el 90% del código son comentarios. Además, tiene que haber la mayor cantidad posible de código sin sentido y mal legible, ¡para que sea posible poner más comentarios!

Pero cuando sea mayor podré publicar los comentarios en forma de libro "Forex y yo" )))). No, prefiero que sea "Yo y Forex".

 
Alexey Volchanskiy:

Y luego escoge tus ojos para saber a qué se refieren esos cuatro paréntesis de la parte inferior. Este es un estilo de código muy malo. En general MS tiene lo mejor, y el hecho de que MQ profese el estilo K&R no es razón para emularlo. Los tiempos de las tarjetas perforadas y los monitores de 80x24 ya han pasado.


Pero cuando sea mayor podré publicar los comentarios en forma de libro "Forex y yo" )))). No, prefiero "Me and Forex".

Pantalla de trabajo de 27".

No voy a releerlo, pero sí a citarlo: "No escribas funciones que sean siempre constantes y nunca cambien en este estilo"

¿Por qué elegir los ojos sobre una función que se escribe una vez cuando se lanza la plataforma y que nunca cambiará en el futuro? ¿Suele cambiar/editar el código en las funciones para obtener el tamaño del lote, el número de órdenes y lo típico? Entonces, ¿por qué estirarlo en 3 pantallas de un monitor de 32"?

P.D. El código adjunto está forjado en kodobase.

 
Vitaly Muzichenko:

Pantalla de trabajo de 27".

No voy a releerlo, me limitaré a citarlo: "No escribas funciones que sean siempre constantes y nunca cambien en ese estilo"

¿Por qué elegir los ojos sobre una función que se escribe una vez cuando se lanza la plataforma y que nunca cambiará en el futuro? ¿Suele cambiar/editar el código en las funciones para obtener el tamaño del lote, el número de órdenes y lo típico? Entonces, ¿por qué extenderlo a través de 3 pantallas de un monitor de 32"?

El archivo donde reposan se abre una vez cada trescientos años de la misma manera.

Y cuando se abra, ve a buscar en el montón }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} qué es lo que hay.

¿Por qué escribirías una trampa para ti mismo si la escribiste, la probaste y la enviaste a una biblioteca o a una clase para almacenarla? Eso es todo. Y cuando necesites refrescar tu memoria (puede ser, que necesites hacer algo en base a ella, lo que sea... que necesites añadir algo ) - sólo tienes que sentarte y mover paréntesis...

 
Vitaly Muzichenko:

Pantalla de trabajo de 27".

No voy a releerlo, me limitaré a citarlo: "No escribas funciones que sean siempre constantes y nunca cambien en ese estilo"

¿Por qué elegir los ojos sobre una función que se escribe una vez cuando se lanza la plataforma y que nunca cambiará en el futuro? ¿Suele cambiar/editar el código en las funciones para obtener el tamaño del lote, el número de órdenes y lo típico? Entonces, ¿por qué extenderlo a través de 3 pantallas de un monitor de 32"?

P.D. Se adjunta el código extraído de kodobase.

Vitaly, la primera versión de tu función muestra claramente qué corchete de cierre se refiere a cuál de apertura, mientras que la segunda versión te rompe los ojos buscando un par...

Por lo general, las funciones personalizadas no son tan grandes como para no caber en la pantalla. Y no importa en absoluto cómo estén dispuestos los paréntesis en el EA compilado.

 
Artyom Trishkin:

El archivo donde yacen también se abre una vez cada trescientos años.

Pero cuando se abra, tendrás que buscar en la pila de }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} para saber qué contiene.

Por qué escribir una trampa para ti, si la escribes, la pruebas y la envías a la biblioteca o a la clase para que la guarden. Eso es todo. Y cuando sea necesario refrescar la memoria (tal vez hacer algo en base a ella, nunca se sabe...) - sólo hay que sentarse y mover paréntesis...

No, no tengo nada en el archivo, no soy avaricioso y comparto programas con conocidos y muy a menudo, y en lugar de enviar archivos, envío sólo un archivo.

Todas las funciones están en la parte inferior, pero el código ejecutivo está siempre bien escrito y comentado, incluso un niño puede entenderlo.

 
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 EAs complejos, ¿quizás hay algunas herramientas o técnicas para tratar con algoritmos tan complejos?

Tengo varios miles de líneas de código en cualquier EA. (Se incluyen automáticamente a través de las inclusiones).

De hecho, un EA consiste en la clase-plantilla CExpert, que tiene funciones OnInit, OnTick, etc. En la plantilla de conexión del EA, todas las funciones globales - eventos - llaman a las funciones correspondientes de este tipo de objeto.

Durante la inicialización - CExpert solicita a través de la función global predefinida "fábrica de piezas EA", que sabe cómo crear todo lo necesario para el trabajo.

El Asesor Experto en sí consta de cinco líneas. En este archivo se declara el objeto de la fábrica de piezas del EA y se incluyen las inclusiones.

Personalmente, me gusta mucho el enfoque OOP, con la división de interfaces virtuales e implementación. En primer lugar, describimos el archivo de la interfaz: una clase abstracta en la que todas las funciones son virtuales e iguales a cero. Esta clase define el "protocolo de interacción". Y luego, heredamos de ella verdaderas clases en las que todas estas funciones están completamente implementadas (a veces tenemos toda una jerarquía de clases, cuando la descripción de las funciones se distribuye "por niveles").

Este enfoque - permite separar las entidades, lo que hace que sea muy fácil de apoyar aún más todo el proyecto, así como la reutilización de las clases.

1234567
Nuevo comentario
Razón de la queja: