Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Mihail Matkovskij:
Obwohl es möglich ist, sie zu umgehen, stellt sich die Frage, warum, wenn es in anderen modernen Kerneln keine solchen Probleme gibt?
Obwohl der Fehler nicht kritisch ist, ist er dennoch lästig.
Es handelt sich nicht um einen Fehler, sondern eher um eine Benachrichtigung. In einigen Sprachen gibt es nicht einmal derartige Meldungen. Wenn sich etwas im lokalen Bereich mit etwas Höherem überschneidet, dann ist das eben so. So war es auch gedacht. Aber in manchen Fällen ist eine solche Warnung durchaus sinnvoll.
In MQL zum Beispiel haben globale Variablen nichts damit zu tun, und meine Empfehlung, sie nicht zu verwenden, ist ebenfalls irrelevant:
Erstellen Sie mehrere Geltungsbereiche:
Und siehe da, wir erhalten zwei Warnungen.
Daher die Schlussfolgerung -
1) solche Warnungen ignorieren
2) Vermeiden Sie die Verwendung der gleichen Namen in den Sichtbarkeitsbereichen darunter/oben
3) den Service Desk überzeugen, diese Meldung als nutzlos zu entfernen
3) den Service Desk überzeugen, diese Meldung als nutzlos zu entfernen
Wenn jeder Idiot den Servicedesk davon überzeugt, diese oder jene Regel zu streichen, weil sie aus seiner Sicht nutzlos ist, wird die Sprache bald zu einem primitiven Schund verkommen.
Ich meine, wie kann sie nicht geschaffen werden? Jede Programmiersprache kann globale Variablen verwenden, und das ist auch gut so, aber hier flucht der Compiler. Obwohl der Fehler nicht kritisch ist, ist er dennoch lästig.
Der variable Punkt gibt den Preis von 1 Punkt an und ist ein Ersatz für den Standardpunkt. Die Funktion MarketInfo(EA_Symbol(), MODE_POINT) gibt den Preis von 1 Punkt für jedes Symbol an. Außerdem kann die Variable point in jeder Funktion im Körper des EA verwendet werden, sofern es sich um eine globale Variable handelt. Ich stimme zu, dass solche Fälle oft zu Unannehmlichkeiten führen (wenn Sie sicherlich Erfahrung in der MQL-Programmierung haben). Und obwohl sie vermieden werden können, stellt sich doch die Frage, warum, wenn es in anderen modernen Sprachen solche Probleme einfach nicht gibt?
Leider verstehen nur erfahrene Programmierer die Nützlichkeit und Bedeutung einer solchen Warnung.
Nun, ich empfehle allen anderen, sich über diese Hilfe des Compilers zu freuen und ihre eigenen Fehler zu beheben. Dies sind echte Fehlerquellen, und gerade für unerfahrene Entwickler ist es von entscheidender Bedeutung, dies zu lernen.
Ich hätte gerne ein Farbschema. Nicht nur im Editor, sondern auch in anderen Fenstern, so dass der Text und die Hintergrundfarbe geändert werden können.
Die Daten der Klassenmitglieder sollten nicht in der Farbe der Instanzvariablen gefärbt werden, wenn die Namen übereinstimmen.
Schon mehrmals habe ich beim Beenden des Arbeitstages und beim Schließen von Programmfenstern, Browsern usw. versehentlich auch das im Optimierungsmodus laufende MT5-Terminal geschlossen. Somit gingen alle Ergebnisse verloren. Ein Neustart des Terminals beginnt von vorne.
Bei vielen Programmen werden Sie beim Schließen eines Fensters gefragt, ob Sie es wirklich schließen wollen, und nicht gespeicherte Daten können verloren gehen.
Dies ist sinnvoll, wenn das Terminal optimiert werden soll.
Es ist nicht einmal ein Fehler, es ist eine Meldung. In einigen Sprachen gibt es diese Art von Benachrichtigung gar nicht. Etwas in einem lokalen Bereich überschnitt sich mit etwas auf einer höheren Ebene, also gut. So war es auch gedacht. Aber in manchen Fällen ist eine solche Warnung durchaus sinnvoll.
In MQL zum Beispiel haben globale Variablen nichts damit zu tun, und meine Empfehlung, sie nicht zu verwenden, ist ebenfalls irrelevant:
Erstellen Sie mehrere Geltungsbereiche:
Und siehe da, wir erhalten zwei Warnungen.
Daraus ergibt sich die Schlussfolgerung.
1) solche Warnungen ignorieren
2) nicht die gleichen Namen in den Sichtbarkeitsbereichen unten/oben machen
3) überzeugen Sie servicedesk, diese Meldung als nutzlos zu entfernen
Nun, 2 Variablen mit demselben Namen in einem Bereich sind nicht gut und jeder Programmierer weiß das. Das Problem ist jedoch, dass dieser Bereich Standardmodule umfasst, an denen ein durchschnittlicher Programmierer nicht herumpfuschen würde, da er sich nicht als Entwickler sieht. Die Warnungen zu entfernen ist auch keine Option. Sie nicht zu beachten, ist auch sehr lästig, weil man wichtige Warnungen übersehen könnte.
Ich sehe hier 2 Möglichkeiten, das Problem zu lösen.
1. Das Plugin soll das Plugin-Programm nicht sehen, wenn es nicht explizit angegeben ist
2. Wenn die Entwickler nicht bereit sind, die Syntax zu ändern, sollte eine Regel für die Deklaration von Parametern in Funktionen eingeführt werden, ähnlich wie bei Klassenfeldern, z.B. sollten Parameternamen mit i oder i_ (aus dem Alphabet Input) beginnen und so alle Parameter in Standardmodulen fixieren.
Der Compiler arbeitet korrekt und diese Warnungen sind ausnahmsweise korrekt.
Es gibt nur einen Ausweg: keine variable Überschneidung zulassen und nicht versuchen, das Recht, Fehler zu machen, mit der Forderung zu wahren, dass der Rest von uns dieses Recht respektiert.
Der Compiler arbeitet korrekt und diese Warnungen sind ausnahmsweise korrekt.
Es gibt nur einen Ausweg: keine variable Überschneidung zulassen und nicht versuchen, das Recht, Fehler zu machen, mit der Forderung zu wahren, dass andere dieses Recht respektieren.