Diskussion zum Artikel "Tipps von einem professionellen Programmierer (Teil I): Code speichern, debuggen und kompilieren. Arbeiten mit Projekten und Protokollen"

Neuer Kommentar
 

Neuer Artikel Tipps von einem professionellen Programmierer (Teil I): Code speichern, debuggen und kompilieren. Arbeiten mit Projekten und Protokollen :

Dies sind einige Tipps von einem professionellen Programmierer über Methoden, Techniken und Hilfsmittel, die das Programmieren erleichtern können.

Terminal-Programmdateien befinden sich im MQL5-Verzeichnis. Dieses Verzeichnis ist eine sogenannte "Sandbox" (Sandkasten). Der Datenzugriff von außen ist geschlossen. Dies ist eine gute Entscheidung. Die Verwendung einer DLL ermöglicht aber wahrscheinlich den Zugriff von überall her.

Hier ist zum Beispiel die Struktur des Cayman-Projekts:

  • /Experts/Cayman/ - Expert Advisor
  • /Files/Cayman/ - data files (settings, parameters)
  • /Include/Cayman/ - library of classes (functions)
  • /Scripts/Cayman/ - main operational scripts
  • /Scripts/CaymanDev/ - developer scripts (used for debugging)

Die Hauptvorteile dieser Anordnung sind:

  • Kontextuelle Suche nur in Projektdateien über TotalCommander
  • Versionskontrolle über Git (Kontrolle wird nur für die Projektdateien aktiviert, alle anderen Dateien werden ignoriert)
  • Einfaches Kopieren auf ein anderes Terminal (Demo -> Real - Freigabe)

Autor: Malik Arykov

 

Ich danke Ihnen. Ein guter, nützlicher Artikel.

 
Interessant ) Ich habe meine Bibliothek mit einem Link versehen. Ich habe sechs verschiedene Terminals und es ist sehr unpraktisch, wenn jedes Terminal seine eigene Kopie der Bibliothek hat. Aber hier ist es immer die gleiche für alle Terminals. Verwenden Sie die .gitattributes-Datei? Und wenn ja, in welcher Form?
 
Guter Artikel. Ich habe meine Dokumente immer auf einen systemfremden Datenträger wie diesen gezogen, nur für den Fall).
 

Bitbucket hat standardmäßig seinen eigenen, ganz normalen Bugtracker, man muss keinen externen starten.

Links sind für Amateure, es ist einfacher, durch ein Repository zu arbeiten, dann stellt sich die Frage nach der Anzahl der Kopien einfach nicht

Interessante Meinung zu externen Editoren, insbesondere wenn man die Vorliebe des Autors für Skripte bedenkt

 
Andrei Novichkov:
Verwenden Sie die Datei .gitattributes? Und wenn ja, in welcher Form?

Ich verwende sie nicht, da es keinen Bedarf gibt. Ich interessiere mich nicht für Binärdateien (einschließlich Bilder, docx) und ihre Deltas. Ich interessiere mich nur für die Texte meiner Programme und ihre Geschichte.

 
Andrei Trukhanovich:

Bitbucket hat standardmäßig einen eigenen, ganz normalen Bugtracker, Sie müssen keinen externen starten.

Links sind für Amateure, es ist einfacher, durch ein Repository zu arbeiten, dann stellt sich die Frage nach der Anzahl der Kopien einfach nicht

Interessante Meinung zu externen Editoren, insbesondere wenn man die Vorliebe des Autors für Skripte bedenkt

1) Ein Kanban Board ist kein Bug Tracker. Ich kann die Aufgaben mehrerer Repositories (MQL4, MQL5, WebSite) des Cayman-Projekts auf einem Board verwalten.

2) Ich habe richtig verstanden, dass, wenn ich zwei Terminals mit demselben MQL5-Inhalt habe , jedes MQL5 ein lokales Repository und ein gemeinsames Cloud-Repository hat. Wenn ja, stellen wir uns die Situation vor. Sie nehmen Änderungen in einem MQL5 vor und möchten sie auf das zweite MQL5 übertragen. Ihre Aktionen:

  • Push des ersten MQL5 - Übertragen der Version in der Cloud
  • Ziehen Sie das zweite MQL5 - aktualisieren Sie die Version.

Warum so viele Schritte?

3) Ich mag die Bequemlichkeit - eine Menge Arbeit mit einem Klick auf ein Skript zu erledigen. NPP bietet mir den Komfort, Protokolle zu markieren. Hier habe ich zum Beispiel mein Log in NPP als Beispiel hervorgehoben. Und die Hervorhebung von Zeilen mit den Token //, Error, todo erfolgt automatisch, da sie in der Syntax von Dateien mit den Erweiterungen *.txt, *.log geschrieben sind

Log-Highlighting

 

Es gibt auch kostenlose Plugins mit Kanban in Bitbucket.

Malik Arykov:

    Warum sich so viel Mühe machen?

    Weil es das Richtige ist.

    Verschiedene Terminals - verschiedene Instanzen, nicht zu erwähnen, dass in einem Terminal kann in der zweiten Debugging arbeiten und dass Terminals können radikal in Instrumenteneinstellungen und Handelsbedingungen unterscheiden.

    Außerdem gibt es Nuancen, wenn das Terminal neue kompilierte Versionen aufnimmt (es ist besser, den Code überhaupt nicht zu kompilieren, wenn er jetzt auf dem Terminal läuft).

    Es ist seltsam, erst von Repositories zu sprechen und dann die Verwendung symbolischer Links vorzuschlagen, obwohl diese natürlich in bestimmten Situationen nützlich sein können.

     
    Andrei Trukhanovich:

    Es ist seltsam, erst über Repositories zu sprechen und dann die Verwendung von symbolischen Links vorzuschlagen, obwohl diese in bestimmten Situationen natürlich auch nützlich sein können.

    Nun, die Links schauen auf das gleiche lokale Repository (ein MQL5 (*.mq?, *.ex?) für alle Terminals).

    Gleichzeitig hat jedes Terminal seine eigenen Eigenheiten. Zum Beispiel habe ich AppSettings.txt, Parameter von Analysatoren, Terminaleinstellungen, etc. (angegeben in .gitignore)

    Von jedem (beliebigen) Terminal aus können Sie "Bearbeiten" aufrufen und sicher sein, dass Sie denselben Code korrigieren.

     
    Malik Arykov:

    Von jedem (beliebigen) Terminal aus können Sie "Bearbeiten" aufrufen und sicher sein, dass Sie denselben Code korrigieren.

    Das ist genau das, was beängstigend ist.)

    aber der Chef ist der Chef.

     

    Git hat jetzt private Repositories.

    Native Git Desktop erkennt mq4/mqh-Dateien als Binärdateien. Selbst wenn ich in den Attributen "diff" angebe, ist nicht klar, wie die Änderungen in der Anwendung angezeigt werden können. Welche Lösungen gibt es, um Dateiversionen bequem zu vergleichen?

    ----

    Wenn Sie Dateien in MTEditor in UTF-8-Kodierung speichern, können Sie Vergleiche über Git Desktop anzeigen

    12
    Neuer Kommentar