Discusión sobre el artículo "Aserciones en los programas MQL5" - página 2

Nuevo comentario
 
Sergey Eremin:

Para que TEST_TEXT sea realmente fácil de eliminar mediante compilación condicional, yo consideraría mover los Prints dentro de la macro. En la versión actual, creo que es fácil eliminar TEST_TEXT, pero no los Prints en sí.

Sí, Sergey, he pensado en ello. Sin embargo, tal vez no he pensado mucho en ello y no he "llegado a ello" todavía.

Simplemente, dependiendo de la situación y de comment(), por ejemplo, se puede utilizar Alert( ) como fuente de salida de información de prueba (para tener una notificación puntual sobre algo sin necesidad de mirar las líneas y si, entre otras cosas, no es molesto y/o se sabe que no va a "parte") en lugar de Print().

Por eso de momento he procedido de la siguiente manera:

  • si se pone #define con palabras clave en el código, basta con comentar o borrar #define;
  • si se pone #define con palabras clave en un fichero de inclusión, basta con comentar o borrar la línea sobre el fichero de inclusión (probablemente me guste más la opción con el fichero de inclusión),

y entonces el compilador te informará rápidamente de las líneas que han quedado inoperativas. E incluso si aplicas la búsqueda, puedes comentar completamente las líneas que no son necesarias en ese momento pulsando un botón en el panel del MetaEditor.

Pero estoy de acuerdo en que es mejor disponer de alguna variante universal.

 
Dina Paches:
Sí, Sergey, he pensado en ello. Sin embargo, quizá es que no he pensado mucho en ello y aún no me he "puesto manos a la obra".

Es que dependiendo de la situación y de comment(), por ejemplo, se puede utilizar Alert() como fuente de salida de información de test (si, entre otras cosas, no molesta) en lugar de Print().

Así que por ahora asumo que

  • si se pone #define con palabras clave en el código, basta con comentar o borrar #define;
  • si se pone #define con palabras clave en un fichero de inclusión, basta con comentar o borrar la línea sobre el fichero de inclusión (probablemente me guste más la opción con el fichero de inclusión),

y entonces el compilador te avisará rápidamente de las líneas que han quedado inoperativas.

Pero formar alguna variante universal por supuesto, estoy de acuerdo, es mejor.

En principio, sí, este enfoque ayuda a limpiar completamente el código de impresiones irrelevantes. Es cierto, cuántas veces sucedió que usted no parece necesitarlo, y luego en un par de meses que lo necesite de nuevo :)

Pero para tal caso, puedes intentar hacer un rolling back a la versión necesaria desde git/svn (como un caso especial de svn - MQL5 Storage), pero con reservas (al hacer un rolling back de una cosa, podemos perder relevancia en otra).

 
Sergey Eremin:

En principio, sí, este enfoque ayuda a limpiar completamente el código de Impresiones irrelevantes. Sin embargo, ha pasado muchas veces que parece que ya no lo necesitas, y luego un par de meses más tarde lo necesitas de nuevo :)

Pero para tal caso se puede intentar hacer un rollback a la versión necesaria desde git/svn (como caso especial de svn - MQL5 Storage), pero con reservas (al hacer rollback en una cosa, podemos perder relevancia en otra).

Al no haber visto aún tu respuesta, lo he añadido a mi post para aclararlo. Pero en cuanto al sentido, sigue siendo el mismo y no se opone a lo que has dicho.

Sí..., tienes razón, después de un tiempo vuelve a ser necesario). Y esas líneas ya han sido "limpiadas" en la versión de trabajo y volver a las anteriores realmente no siempre puede ser razonable.

 
Sergey Eremin:
Pero, en principio, si es necesario, el número de comprobaciones "de prueba" puede seguir siendo obviamente menor que cuando se construye el código desde cero. Pero, de nuevo, esto es juzgar desde el punto de vista de una persona que escribe el código por sí misma y luego lo refina/modifica por sí misma. Es decir, una visión bastante limitada.
 
Sergey Eremin:

P./S.: Me gustaría aclarar que no me refería a "Buscar...", sino a "Ir a una línea determinada" o "Lista de funciones de un archivo".

P./S.: Pero volviendo al artículo, una vez más, muy interesante la posibilidad de aplicar sentencias como las que citas en el artículo. Gracias.

 
Dina Paches:

Al mismo tiempo, habiendo descargado el archivo assert.mqh, le añadí una línea:

Y luego en el código se ve así:

  Print(TEST_TEXT,"a = ",a);

Es decir, que y simplemente al construir el código para aplicar la salida de información con la expectativa de que al final del trabajo en el código a continuación, esta salida de información "de trabajo" puede ser fácilmente eliminado (como muchos, creo, probablemente hizo y hace con la salida de información en las etapas de construcción de código).

También puede encontrar útil esta macro

#define  PRINT(x)  Print(#x,"=",x)
//+------------------------------------------------------------------+
//| Función de inicio del programa de script|
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   PRINT(ORDER_TYPE_BUY_STOP_LIMIT);
   PRINT(ORDER_TYPE_SELL_STOP_LIMIT);
   PRINT(ORDER_POSITION_ID);
   PRINT(POSITION_TYPE_BUY);
   PRINT(POSITION_TYPE_SELL);
   
   PRINT(POSITION_TIME);
   PRINT(POSITION_TIME_MSC);
   PRINT(POSITION_TIME_UPDATE);
   PRINT(POSITION_TIME_UPDATE_MSC);
   PRINT(POSITION_TYPE);
   PRINT(POSITION_MAGIC);
   PRINT(POSITION_IDENTIFIER);
 
Rashid Umarov:

También puede resultarte útil esta macro

Por cierto, creo que sería bueno añadir documentación sobre # y macros multilínea. Aquellos que no han aprendido C pueden estar un poco confundidos por los códigos en el artículo y los comentarios :)
 
Rashid Umarov:

Esta macro puede ser útil

No es posible, pero realmente tal cosa es necesaria en el hogar. Gracias.

Usted da una buena base sobre la que se puede construir la "carne". Entre otras cosas, confirmando una vez más que el genio es simple.

Y, supongo, Sergei probablemente quería decir algo así cuando escribió aquí.

Sin embargo, todavía tengo que entender/familiarizarme con muchas cosas en relación con este tipo de construcciones.

Entre otras cosas, a la hora de aplicar la transformación de datos antes de imprimir (y teniendo en cuenta la impresión no sólo a través de Print, sino también en un comentario o alerta). Y para que el nombre de la variable no se pierda visualmente frente a DoubleToString, por ejemplo, o TimeToString.

Es decir, por ejemplo, ahora lo he escrito así:

#define  TEST_PRINT(x)   Print(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)
#define  TEST_COMMENT(x) Comment(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)
#define  TEST_ALERT(x)   Alert(__LINE__,", ",__FUNCTION__,", ",#x,"=",x)

En la pestaña Expertos se visualiza así:


Y en el gráfico el mismo comentario, en caso de aplicación.

Es decir, la variable precio_0 se "pierde" frente a DoubleToString.

Sin embargo, ya es más fácil de hacer en el código con tal salida #define de cadenas de prueba que di aquí antes. Aunque todavía no es la mejor opción.


P./S.: Ahora pensé que el hecho de que la aplicación de las funciones de transformación es también de salida y claramente visible en el texto de prueba - esto, por el contrario, puede ser útil. En general, no es tanto que se pierda el nombre de la variable. Es sólo que antes no se suponía para mí y no es habitual para los ojos cuando la salida de información.


Sergey Eremin:
Por cierto, creo que sería bueno añadir documentación sobre # y macros multilínea. Los que no han aprendido C pueden estar un poco confundidos por los códigos en el artículo y los comentarios :).
Sería estupendo.
 
P./S.: Ahora, cuanto más miro la salida, más me doy cuenta de que, sí, la salida y las funciones que convierten los datos de un formato a otro son definitivamente convenientes en los registros de prueba. Sólo es cuestión de optimizarlo al máximo.
 
Andrey Shpilev:

1. ¿Por qué macros? Son incómodas, no se les pueden aplicar todas las condiciones y es extremadamente difícil depurarlas si algo va mal. Era más fácil implementar procedimientos triviales.

Este es el caso cuando las macros son la única alternativa.
123
Nuevo comentario