Diskussion zum Artikel "Die Verwendung der Behauptung (assertions) bei der Entwicklung der Programme in MQL5" - Seite 2

Neuer Kommentar
 
Sergey Eremin:

Damit TEST_TEXT wirklich einfach durch bedingte Kompilierung entfernt werden kann, würde ich erwägen, die Prints in das Makro zu verschieben. In der aktuellen Version ist es meiner Meinung nach einfach, TEST_TEXT zu entfernen, aber nicht die Prints selbst.

Ja, Sergey, darüber habe ich nachgedacht. Vielleicht habe ich aber auch nur nicht viel darüber nachgedacht und bin noch nicht dazu gekommen.

Ganz einfach, je nach Situation und comment() kann z.B. Alert( ) anstelle von Print() als Quelle für die Ausgabe von Testinformationen verwendet werden (um eine prompte Benachrichtigung über etwas zu haben, ohne auf die Zeilen schauen zu müssen, und wenn es u.a. nicht lästig ist und/oder bekannt ist, dass es nicht "abhaut").

Deshalb bin ich vorerst von folgendem ausgegangen:

  • wenn #define c-Schlüsselwörter im Code stehen, reicht es, #define auszukommentieren oder zu löschen;
  • wenn #define mit Schlüsselwörtern in eine Include-Datei gesetzt wird, reicht es, die Zeile über die Include-Datei auszukommentieren oder zu löschen (die Variante mit der Include-Datei gefällt mir wahrscheinlich besser),

und dann wird der Compiler Sie schnell über die unwirksam gewordenen Zeilen informieren. Und selbst wenn man die Suche anwendet, kann man Zeilen, die im Moment nicht benötigt werden, komplett auskommentieren, indem man einen Knopf im MetaEditor-Panel drückt.

Aber ich stimme zu, dass es besser ist, eine universelle Variante zur Verfügung zu haben.

 
Dina Paches:
Ja, Sergey, ich habe darüber nachgedacht. Aber vielleicht habe ich auch nur noch nicht viel darüber nachgedacht und bin noch nicht "in die Gänge gekommen".

Es ist nur so, dass je nach Situation und comment() z.B. Alert( ) anstelle von Print() als Quelle für die Ausgabe von Testinformationen verwendet werden kann (wenn es u.a. nicht störend ist).

Ich gehe also vorerst davon aus, dass:

  • wenn #define c Schlüsselwörter in den Code eingefügt werden, reicht es aus, #define auszukommentieren oder zu löschen;
  • wenn #define mit Schlüsselwörtern in eine Include-Datei gesetzt wird, reicht es, die Zeile über die Include-Datei auszukommentieren oder zu löschen (die Option mit der Include-Datei gefällt mir wahrscheinlich besser),

und dann wird der Compiler Sie schnell über die Zeilen informieren, die unwirksam geworden sind.

Aber eine allgemeingültige Variante zu bilden, halte ich natürlich für besser.

Im Prinzip, ja, dieser Ansatz hilft, den Code vollständig von irrelevanten Prints zu reinigen. Es ist wahr, wie oft es passiert ist, dass man es nicht zu brauchen scheint, und dann in ein paar Monaten braucht man es wieder :)

Aber für solche Fälle kann man versuchen, auf die benötigte Version von git/svn (als Spezialfall von svn - MQL5 Storage) zurückzurollen, aber mit Vorbehalten (durch das Zurückrollen einer Sache können wir Relevanz in einer anderen verlieren).

 
Sergey Eremin:

Im Prinzip hilft dieser Ansatz ja, den Code vollständig von irrelevanten Prints zu befreien. Allerdings ist es schon oft vorgekommen, dass man es nicht mehr zu brauchen scheint, und dann ein paar Monate später braucht man es wieder :)

Aber für solche Fälle kann man versuchen, auf die benötigte Version von git/svn (als Spezialfall von svn - MQL5 Storage) zurückzurollen, aber mit Vorbehalten (durch das Zurückrollen einer Sache können wir Relevanz in einer anderen verlieren).

Da ich Ihre Antwort noch nicht gesehen habe, habe ich meinen Beitrag ergänzt, um ihn zu verdeutlichen. Aber von der Bedeutung her bleibt es dasselbe und steht nicht im Widerspruch zu dem, was Sie gesagt haben.

Ja..., Sie haben Recht, nach einiger Zeit ist es wieder notwendig). Und diese Zeilen sind in der Arbeitsversion bereits "bereinigt" worden, und ein Zurückgehen auf frühere Versionen ist nicht immer sinnvoll.

 
Sergey Eremin:
Aber im Prinzip kann die Anzahl der "Test"-Prüfungen, falls erforderlich, immer noch deutlich geringer sein, als wenn der Code von Grund auf neu erstellt wird. Aber auch hier gilt, dass dies aus der Sicht einer Person zu beurteilen ist, die den Code selbst schreibt und ihn dann selbst verfeinert/verändert. Das ist eine ziemlich eingeschränkte Sichtweise.
 
Sergey Eremin:

P./S.: Ich möchte klarstellen, dass ich nicht mit "Suchen...", sondern mit "Gehe zu einer bestimmten Zeile" oder "Liste der Funktionen in einer Datei" meinte.

P./S.: Aber um noch einmal auf den Artikel zurückzukommen: Die Möglichkeit, Anweisungen, wie Sie sie im Artikel anführen, anzuwenden, war sehr interessant. Danke dafür.

 
Dina Paches:

Gleichzeitig habe ich die Datei assert.mqh heruntergeladen und ihr eine Zeile hinzugefügt:

Und dann in den Code sieht es so aus:

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

Das heißt, dass und einfach bei der Konstruktion des Codes, um die Ausgabe von Informationen mit der Erwartung, dass bis zum Ende der Arbeit an den Code dann diese Ausgabe von "Arbeits"-Informationen kann leicht entfernt werden (wie viele, ich glaube, wahrscheinlich tat und tut mit der Ausgabe von Informationen in den Stadien der Code-Konstruktion) gelten.

Vielleicht finden Sie auch dieses Makro nützlich

#define  PRINT(x)  Print(#x,"=",x)
//+------------------------------------------------------------------+
//| Skript-Programmstartfunktion|
//+------------------------------------------------------------------+
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:

Vielleicht finden Sie auch dieses Makro nützlich

Übrigens wäre es gut, eine Dokumentation über # und mehrzeilige Makros hinzuzufügen. Diejenigen, die C nicht gelernt haben, könnten durch die Codes im Artikel und in den Kommentaren ein wenig verwirrt sein :)
 
Rashid Umarov:

Dieses Makro könnte nützlich sein

Nicht möglich, aber wirklich so etwas ist im Haushalt notwendig. Ich danke Ihnen.

Sie geben eine gute Basis, auf der Sie das "Fleisch" aufbauen können. Unter anderem, um noch einmal zu bestätigen, dass das Genie einfach ist.

Und ich vermute, dass Sergei wahrscheinlich so etwas gemeint hat, als er hier schrieb.

Allerdings muss ich noch viele Dinge im Zusammenhang mit solchen Konstruktionen verstehen/kennenlernen.

Unter anderem bei der Anwendung der Datentransformation vor dem Drucken (und unter Berücksichtigung des Druckens nicht nur über Print, sondern auch in einem Kommentar oder einer Meldung). Und damit der Variablenname z.B. bei DoubleToString oder TimeToString nicht visuell verloren geht.

Das heißt, ich habe es jetzt zum Beispiel so geschrieben:

#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)

In der Registerkarte Experten wird es so angezeigt:


Und auf dem Diagramm der gleiche Kommentar, im Falle der Anwendung.

Das heißt, die Variable price_0 ist gegen DoubleToString "verloren".

Allerdings ist es schon einfacher, im Code mit solchen #define-Ausgaben von Teststrings zu arbeiten, als ich es hier vorhin getan habe. Obwohl es immer noch nicht die beste Option ist.


P./S.: Nun dachte ich, dass die Tatsache, dass die Anwendung der Transformationsfunktionen auch ausgegeben wird und im Testtext deutlich sichtbar ist - das kann im Gegenteil nützlich sein. Generell ist es ja nicht so, dass der Variablenname verloren geht. Es ist nur so, dass es früher für mich nicht vorgesehen war und es ist nicht üblich für die Augen bei der Ausgabe von Informationen.


Sergey Eremin:
Übrigens, ich denke, es wäre gut, eine Dokumentation über # und mehrzeilige Makros hinzuzufügen. Diejenigen, die C nicht gelernt haben, könnten durch die Codes im Artikel und in den Kommentaren ein wenig verwirrt sein :).
Das wäre großartig.
 
P./S.: Je mehr ich mir die Ausgabe ansehe, desto mehr wird mir klar, dass die Ausgabe und die Funktionen, die Daten von einem Format in ein anderes konvertieren, in Testdatensätzen durchaus praktisch sind. Es geht nur darum, dies so weit wie möglich zu optimieren.
 
Andrey Shpilev:

1. Warum Makros? Sie sind unbequem, nicht alle Bedingungen können ihnen zugeführt werden, und es ist extrem schwierig, sie zu debuggen, wenn etwas schief geht. Es war einfacher, triviale Prozeduren zu implementieren.

Dies ist der Fall, wenn Makros die einzige Alternative sind.
123
Neuer Kommentar