Merkmale der Sprache mql4, Feinheiten und Techniken - Seite 11

Neuer Kommentar
 
Ihor Herasko:

In vielen Softwareunternehmen würde man sich für einen solchen Code die Finger abhacken. Das erste, was immer und überall erforderlich ist, ist die Vermeidung von "unnötigem Lesen". Zum Beispiel, wenn eine Bedingung bei der Eingabe einer Funktion verwendet wird:

dann ist es empfehlenswert, zu schreiben:

Dieser Ansatz ist sehr hilfreich, wenn keine Bedingungen gestellt werden.

Das wird wieder einmal sehr mühsam sein. Schließlich hat niemand überprüft, was die Funktion OrderType() zurückgibt. Oder vielleicht hat er -1 oder 6 zurückgegeben? Dies ist ein Beispiel dafür, dass man sich auf die Eigenschaften des Compilers stützt, was man auf jeden Fall vermeiden sollte. Sie selbst führen viele Beispiele für plattformübergreifenden Code an. Warum weichen Sie also in diesem Fall davon ab? Wenn ein neuer MQ-Compiler herauskommt, wird dieser Code nicht mehr korrekt funktionieren.

Was haben Softwarefirmen mit dem zu tun, worüber wir hier sprechen? Der Code wird weiter funktionieren, hier besteht kein Bedarf an Cospirologie.

Das Gleiche gilt für die Fortsetzung. Code wie:

ist schwieriger zu lesen als:

Und doch ist die Effizienz der Ausführung in beiden Fällen die gleiche.

In diesem Fall ist ein einzeiliger Code leichter zu lesen als ein sechszeiliger Code. Außerdem ist sie logischer, weil sie nicht an eine Schleife gebunden ist. Das heißt, Sie können den ersten Fall kopieren und einfügen, ohne sich um den zweiten Fall zu kümmern.

 
fxsaber:

Das obige Lots[]-Beispiel ist eine Fundgrube dafür, wie Code sowohl super-lakonisch als auch völlig verständlich sein kann.

Sie sind es, der den Code verständlich findet. Aber jemand, der nur die Dokumentation liest und Ihren Code sieht, wird sich fragen, warum die Größe des Arrays 8 beträgt, während die Dokumentation nur 6 Auftragstypen enthält.

Und ich persönlich finde es auch einfacher, Bedingungen zu lesen, wenn sie getrennt sind, z. B. so:

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

Ich fühle mich auch viel wohler als so:

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

Aber ich denke, das ist eine Frage des Geschmacks und der Gewohnheit. Niemand muss etwas aufzwingen oder beweisen.

Andererseits stimme ich Ihnen zu, dass:

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

Und ich denke, das ist logisch, und ich kann mich an keine anderen Zeiten erinnern.

 
Alexey Kozitsyn:

Für Sie ist der Code verständlich. Aber jemand, der gerade die Dokumentation durchgesehen und Ihren Code gesehen hat, wird sich sofort fragen, warum das Array die Größe 8 hat, während die Auftragstypen in der Dokumentation nur 6 sind.

Sie sehen also, wie ein einfacher Code die richtigen Fragen in den Köpfen der Menschen erzeugt! Und sollten Sie danach alles glauben, was in der Dokumentation steht?

 
fxsaber:

Und sollte man danach alles in der Dokumentation glauben?

Sie sollten es tun, es ist ein Grundprinzip derRTFM-Programmierung

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

sollte, ist es ein Grundprinzip derRTFM-Programmierung

Die Realität widerspricht diesem Grundsatz.

 
fxsaber:

Was haben Softwarefirmen mit dem zu tun, worüber wir hier sprechen?

Wen können Sie noch als Autorität anführen?

Der Code wird weiter funktionieren, hier ist keine Cospirologie nötig.

Ja, in MT4 ist es mit 99%iger Wahrscheinlichkeit so, denn MT4 ist fast begraben. Versucht man jedoch, ein solches Kunststück plattformübergreifend durchzuführen, stößt man sofort auf einen verschwindenden Defekt, der zu einem fatalen Fehler führt.

In diesem Fall ist der einzeilige Code leichter zu lesen als der sechszeilige Code. Außerdem ist es logischer, weil es nicht an die Notwendigkeit gebunden ist, sich in einer Schleife zu befinden. Das heißt, der erste Fall kann leicht kopiert werden, der zweite nicht.

Wenn es sich um einen bestimmten Fall handelt, kann dies zutreffen, denn der angegebene Code ist nahezu Standard für jeden EA. Aber wenn man etwas Komplizierteres nimmt, ist es schwer zu lesen, wenn man es in einer Zeile schreibt.

Warum sollten Sie sich Flüche aus dem Weltall von jemandem anhören, der mit Ihrem Code arbeitet? ))

 
Ihor Herasko:

Wen können Sie noch als Autorität anführen?

Es ist merkwürdig, dass der Begriff der Autorität hier angesprochen wird.

Ja, bei MT4 besteht eine 99%ige Wahrscheinlichkeit, dass dies der Fall ist, da MT4 fast begraben ist. Versucht man jedoch, ein solches Kunststück plattformübergreifend durchzuführen, stößt man sofort auf einen verschwindenden Defekt, der zu einem fatalen Fehler führt.

Das Schreiben im MT5 ist identisch.

Wenn es sich um einen bestimmten Fall handelt, kann dies der Fall sein, da der angegebene Code für jeden EA nahezu standardmäßig ist. Aber wenn man etwas Komplizierteres nimmt, ist es schwer zu lesen, wenn es in einer Zeile geschrieben ist.

Und es gibt auch Konstruktionen if -> else if -> else. Ich verstehe nicht, warum ein bool-Ausdruck in einem bedingten Operator in der primitivsten Form angegeben werden muss.

 
Alexey Kozitsyn:

Für Sie ist der Code verständlich. Aber jemand, der gerade die Dokumentation durchgesehen und Ihren Code gesehen hat, wird sich sofort fragen, warum das Array die Größe 8 hat, während die Auftragstypen in der Dokumentation nur 6 sind.

Und ich persönlich finde es auch einfacher, Bedingungen zu lesen, wenn sie getrennt sind, z. B. so:

Ich fühle mich auch viel wohler als so:

Aber ich denke, das ist eine Frage des Geschmacks und der Gewohnheit. Niemand muss etwas aufzwingen oder beweisen.

Andererseits stimme ich Ihnen zu, dass:

Und ich denke, das ist logisch, und ich kann mich an keine anderen Zeiten erinnern.

Das sind die Schlüsselwörter.

Mich persönlich stört die Schreibweise von continue überhaupt nicht.

Was ist der Sinn von???? Wenn Sie lesen 

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

alles liest sich russisch:

Wenn der Auftrag ausgewählt wird und das Auftragssymbol "unseres" ist und der Magier auch unseres ist... dann machen wir alles in geschweiften Klammern.

Aber das klingt nicht sehr russisch:

Wenn der Haftbefehl nicht ausgewählt ist, verpiss dich...

Wenn das Haftbefehlssymbol nicht von uns ist, verpiss dich...

und so weiter.

Wie oft müssen wir uns noch selbst dorthin schicken...................

Offensichtlich war dies in mql3 sinnvoll. Auf diese Weise konnte die Zeit für die Überprüfung des Zustands verkürzt werden. Dann werden alle Bedingungen von Anfang bis Ende überprüft. Das Problem ist jedoch längst gelöst: Wenn die Prüfung auf eine nicht erfüllte Bedingung stößt, werden weitere Prüfungen abgebrochen. Und all diese Tricks machen absolut keinen Sinn.

 
Alexey Viktorov:

Dies sind die Schlüsselwörter.

Mich persönlich stört die Schreibweise von "continue" überhaupt nicht.

Was ist der Sinn von???? Wenn Sie lesen

steht alles auf Russisch:

Wenn der Auftrag ausgewählt wird und das Auftragssymbol "unseres" ist und der Magier auch unseres ist... dann machen wir alles in geschweiften Klammern.

Aber das klingt nicht sehr russisch:

Wenn der Haftbefehl nicht ausgewählt ist, verpiss dich...

Wenn das Haftbefehlssymbol nicht von uns ist, verpiss dich...

und so weiter.

Wie oft müssen wir uns noch selbst dorthin schicken...................

Das muss in mql3 Sinn gemacht haben. Auf diese Weise konnte die Zeit für die Prüfung einer Bedingung verkürzt werden. Damals wurden alle Bedingungen von Anfang bis Ende überprüft. Das Problem ist jedoch längst gelöst: Wenn eine Kontrolle auf eine nicht erfüllte Bedingung stößt, werden weitere Kontrollen eingestellt. Und all diese Tricks machen absolut keinen Sinn.

Sie haben selbst zugegeben, dass es eine Frage der Gewohnheit ist. Mich stören zum Beispiel unnötige Verschachtelungen, ich entferne sie immer mit return, continue. Und anstelle von "in die Hölle kommen" kann man sich leicht daran gewöhnen, zu lesen "die Bedingungen 1 und 2 sind erfüllt":

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

Mich stören zum Beispiel unnötige Verschachtelungen, ich entferne sie immer mit return, continue

Mich irritiert die"Boolesche Negation NOT(!)", sie kostet nicht nur einen CT, sondern das Lesen eines logischen Ausdrucks wird zu einem "Hin- und Herlesen" )))

Ich gebe bei boolschen Funktionen immer "true" als die am ehesten zu erwartende Antwort zurück, z. B. prüfe ich auf diese Weise die Serververfügbarkeit:

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);}

Ich nenne sie recht lesbar und logisch:

if(ServerDisable()) return;

wenn der Server ausgelastet ist - Exit, ich benutze das normalerweise bei Handelsfunktionen, es gibt keinen Grund, den Server mit Anfragen zu belästigen, weil er ausgelastet ist

wie man so schön sagt - Geschmackssache, aber wie Sie wissen: Geschmäcker sind verschieden ))))

1...456789101112131415161718...35
Neuer Kommentar