Auto-apprentissage du langage MQL5 à partir de zéro - page 48

 
Si l'objectif immédiat est de mettre en œuvre un simple stop suiveur, vous devez continuer à écrire le script en ajoutant les boucles for et while.

Je ne suis pas sûr que le script "assez de patience" ait une extension logique. Il est probablement préférable de passer à une nouvelle idée qui nécessite d'avoir :

1. Un arbre de conditions if-else.
2. Fonctions de calcul.
3. Cycles.

Comme nous devrons travailler dans le domaine du trading algorithmique, il serait plus pratique que le script soit lié à la stratégie de trading. Pensez-y.

 
Pour une meilleure compréhension des boucles :

Une boucle vous permet de faire passer une section de code fermée dans son corps, encore et encore. Les résultats de chaque passe seront différents des résultats des autres passes, car les valeurs des variables/fonctions appelées peuvent être différentes à chaque passe. Le nombre d'itérations de la boucle est fixé par le programmeur, la valeur de la variable ou de la fonction - cela dépend du code spécifique.
 
MrBrooklin:

Alexei, tu plaisantes ? Oui, j'aimerais d'abord apprendre les bases !

Respectueusement, Vladimir.


Pas beaucoup. A en juger par la dynamique et votre base, la théorie et la pratique - c'est votre profil du début à la fin. Alors pourquoi pas... Pas maintenant, mais plus tard... Quand vous aurez pris le coup de main et que vous tutoierez le code.
 
Реter Konow:
Si votre objectif immédiat est de mettre en place un simple stop suiveur, continuez à écrire le script en ajoutant les boucles for et while.

Je ne suis pas sûr que le script "assez de patience" ait une extension logique. Il est probablement préférable de passer à une nouvelle idée qui nécessite d'avoir :

1. Un arbre de conditions if-else.
2. Fonctions de calcul.
3. Cycles.

Comme nous serons amenés à travailler dans le domaine du trading algorithmique, il serait plus pratique que le script soit lié à la stratégie de trading. Pensez-y.

Merci, Peter, de soutenir mon intention d'équiper le script New7.mq5 de trailing stops, surtout maintenant, alors que j'ai commencé à étudier les cycles. Au fait, j'ai déjà essayé la fonction Sleep dans le script. Il a été recommandé d'utiliser cette fonction lors de l'écriture du trailing stop. Par où commencer ? Il serait sans doute préférable de décrire d'abord l'ensemble de l'algorithme du stop suiveur en mots, puis de passer à l'écriture du code ?

Sincèrement, Vladimir.

 
Aleksey Masterov:

Pas beaucoup. À en juger par la dynamique et votre base, la théorie et la pratique, c'est votre profil du début à la fin. Alors pourquoi pas... pas maintenant, mais plus tard... Quand on a le coup de main et qu'on se tutoie.

Merci, Alexey, pour votre foi en moi. Tout ce que j'ai à faire, c'est de continuer à faire du bon travail !

Sincèrement, Vladimir.

 
MrBrooklin:

Merci, Peter, de soutenir mon désir d'équiper le script New7.mq5 de trailing stops, surtout maintenant, alors que j'ai commencé à étudier les cycles. Au fait, j'ai déjà essayé la fonction Sleep dans le script. Il a été recommandé d'utiliser cette fonction lors de l'écriture du trailing stop. Où dois-je commencer ? Il serait sans doute préférable de décrire d'abord l'ensemble de l'algorithme du stop suiveur en mots, puis de passer à l'écriture du code ?

Sincèrement, Vladimir.

Objectivement, un simple trailing stop ne peut pas être écrit dans le script. Je m'explique : les stops suiveurs n'existent pas par eux-mêmes, dans un "vide", ils sont "liés" à une position ouverte, qui, à son tour, est "liée" à une stratégie, et la stratégie est mise en œuvre uniquement dans un EA.

Le problème et la complexité du suivi dans le script résident dans le fait que vous devez collecter des informations sur les positions ouvertes et leurs ordres dans la boucle, puis sélectionner l'ordre requis sur le symbole requis et calculer sa modification. C'est compliqué et déroutant, mais pour un EA, tout est beaucoup plus facile. Premièrement, vous saurez déjà quel ordre modifier, et deuxièmement, vous saurez quand modifier, car l'événement OnTick arrive.

Donc, vous mettez un "ordre en attente" dans le script, puis il se déclenche, une position est ouverte et vous pouvez suivre le stop... Ce dont vous avez besoin pour cela :

1. Je veux boucler le script.
2. Ecrivez la fonction de fixation de l'événement de changement de prix sur le symbole texte.
3. écrire la fonction de modification de l'ordre d'arrêt.
4. Écrire la condition de déchargement du script (sortie du cycle sans boucle) à la fermeture de la position.

J'ai esquissé les grandes lignes du scénario de manière approximative, mais je vais devoir y réfléchir plus sérieusement.

P.S. La fonction Sleep est utilisée pour retarder l'exécution du code lorsque cela est nécessaire. Par exemple, lors de l'envoi d'une demande au serveur ou de l'attente d'un événement. Dans un script de suivi, cette fonction sera certainement nécessaire.
 
Реter Konow:
Les programmeurs ont peur d'utiliser des variables globales en raison des erreurs qui se produisent lors de la modification de leurs valeurs. Cela crée une situation où une erreur est difficile à localiser car chaque fonction peut les modifier. Bien sûr, seules ces variables doivent exister dans la portée globale que toutes les fonctions du programme doivent voir. Il ne peut en être autrement.

J'ai toujours aimé utiliser des variables globales, car elles permettaient une croissance rapide des fonctionnalités, et le programme s'est transformé en un énorme chantier actif. J'ai souvent été critiqué pour la façon dont j'écris le code, mais c'est pour cela que c'est un chantier de construction : on le nettoie une fois que le travail principal sur le bâtiment est terminé, et quand la maison est construite, on peut commencer à poser le carrelage, à peindre et à nettoyer le terrain. En attendant, la priorité est de monter le coffrage et de couler le béton).

Cependant, les programmeurs pensent différemment. Ils vont "nettoyer" et "épurer" leur code, même s'il s'agit de deux lignes et demie. Ils frotteront leur code même s'il fait deux lignes et demie, mais il brillera comme une pièce neuve). Cette attitude à l'égard du code est justifiée par leur profession dont ils vivent, mais du point de vue de la création, ils sont rigides et peu développés. C'est comme ça...

Mon conseil : apprenez à écrire correctement, mais permettez-vous parfois de vous éloigner des règles et d'expérimenter pour acquérir une expérience plus variée. Cela vous aidera à apprendre et vous apprendrez plus vite.

On observe qu'une fois que l'on commence à s'accrocher, il est difficile de s'arrêter, et par conséquent, le code du projet se transforme en ce qu'on appelle du dre... code.

Laissez-moi vous expliquer :

  1. Vous avez un projet avec une solution de travail intermédiaire et le nombre de fonctionnalités implémentées compte=0.
  2. Notre tâche est d'implémenter la fonctionnalité ++count.
  3. Pour ajouter les fonctionnalités dont nous avons besoin :
    • pour écrire des méthodes de l'arbre d'objets et connecter toutes ces choses aux gestionnaires d'événements avec logique (temps estimé 3 heures *count ; count=0).
    • écrire une béquille sous forme de variable globale et l'utiliser dans plusieurs méthodes, là où nous en avons besoin (temps estimé : 15 min *comptage.).
  4. Bug de la numérotation automatique (c'est un rapport de bug pour les méta-citations).
  5. Naturellement, nous avons choisi une béquille (c'est vraiment difficile de se faire travailler dans ce cas)
  6. si (nous l'avons fait) aller à 2
  7. Sinon, tout part en vrille, on crie "help-mi" et on lit des commentaires hilarants disant que c'est mal de faire ça.

J'espère que vous avez fait attention au fait que le compteur des fonctionnalités implémentées, augmente le temps d'implémentation de la fonctionnalité suivante, mais lorsqu'il est implémenté correctement, il se remet à zéro ?

C'est très exagéré, mais c'est comme ça que ça marche dans la vraie vie.

Ce que je veux dire, c'est que si vous ne réécrivez pas le projet après avoir implémenté toutes les fonctionnalités, il sera mis en production comme un spoiler illisible. Et puis, le cycle de vie de tout projet conduit à un casse-tête pour la direction : soit mettre toute l'équipe sur un refactoring global de toutes ces choses qui ont été filées (et les concurrents ne dorment pas, eux, les méchants, écrivent de nouvelles fonctionnalités), soit continuer à écrire des béquilles et à patcher des bugs, qui fuient en torrents.

 
Реter Konow:
Objectivement, un simple trailing stop ne fonctionnera pas dans le script. Je m'explique : les stops suiveurs n'existent pas par eux-mêmes, dans un "vide", ils sont "liés" à une position ouverte, qui est à son tour "liée" à la stratégie, et la stratégie est mise en œuvre uniquement dans un Expert Advisor.

Le problème et la complexité de la mise en œuvre du suivi dans le script est que vous devez collecter des informations sur les positions ouvertes et leurs ordres dans la boucle, puis sélectionner le bon ordre sur le bon symbole et calculer comment le modifier. C'est compliqué et déroutant, mais pour un EA, tout est beaucoup plus facile. Premièrement, vous saurez déjà quel ordre modifier, et deuxièmement, vous saurez quand modifier, car l'événement OnTick arrive.

Donc, vous mettez un "ordre en attente" dans le script, puis il se déclenche, une position est ouverte et vous pouvez suivre le stop... Ce dont vous avez besoin pour cela :

1. Pour boucler le script.
2. La fonction de fixation de l'événement de changement de prix sur le symbole.
3. Fonction d'écriture de la modification de l'ordre d'arrêt.
4. Ecrivez la condition de déchargement du script (sortie de la boucle) à la fermeture de la position.

J'ai esquissé les grandes lignes du scénario de manière approximative, mais je vais devoir y réfléchir plus sérieusement.

P.S. La fonction Sleep est utilisée pour retarder l'exécution du code lorsque cela est nécessaire. Par exemple, lors de l'envoi d'une requête au serveur ou de l'attente d'un événement. Dans un script de suivi, cette fonction sera certainement nécessaire.

Peter, devons-nous créer un code de fin dans le script ? Parfait ! Maintenant, je prends ce que vous avez énuméré comme sections de base et je commence à les décrire avec des mots, de sorte que la façon dont je dois écrire les fonctions, les boucles, etc. soit claire par la suite. Est-ce correct ?

Salutations, Vladimir.

 
MrBrooklin:

Peter, donc on crée le code de fin dans le script ? Super ! Ce que vous avez énuméré, je le considère maintenant comme des sections de base et je commence à les décrire avec des mots, de sorte que la façon d'écrire les fonctions, les boucles, etc. soit claire plus tard. Est-ce correct ?

Salutations, Vladimir.

Oui, c'est ça.
 
Vladimir Simakov:

On observe qu'une fois que l'on commence à croquer, il est difficile de s'arrêter, et par conséquent, le code du projet se transforme en ce que l'on appelle du d.c..

Laissez-moi vous expliquer :

  1. Vous avez un projet avec une solution de travail intermédiaire et le nombre de fonctionnalités implémentées compte=0.
  2. Notre tâche consiste à mettre en œuvre la fonctionnalité ++count.
  3. Pour ajouter les fonctionnalités dont nous avons besoin :
    • pour écrire des méthodes de l'arbre d'objets et connecter toutes ces choses aux gestionnaires d'événements avec logique (temps estimé 3 heures *count ; count=0).
    • écrire une béquille sous forme de variable globale et l'utiliser dans plusieurs méthodes, là où nous en avons besoin (temps estimé : 15 min *comptage.).
  4. Bug de la numérotation automatique (c'est un rapport de bug pour les méta-citations).
  5. Naturellement, c'est la version béquille qui a été choisie (il est vraiment difficile de se faire la main dans ce cas)
  6. si (nous l'avons fait) aller à 2
  7. Sinon, tout part en vrille, on crie "help-mi" et on lit des commentaires hilarants disant que c'est mal de faire ça.

J'espère que vous avez fait attention au fait que le compteur des fonctionnalités implémentées, augmente le temps d'implémentation de la fonctionnalité suivante, mais lorsqu'il est implémenté correctement, il se remet à zéro ?

C'est une idée très exagérée, mais c'est ainsi que cela fonctionne dans la vie réelle.

Ce que je veux dire, c'est que si vous ne réécrivez pas le projet après avoir implémenté toutes les fonctionnalités, il sera mis en production comme un spoiler illisible. Et puis, le cycle de vie de tout projet conduit à un casse-tête pour la direction : soit mettre toute l'équipe sur un refactoring global de toutes ces choses qu'ils ont filées (et les concurrents sont réveillés, eux, les méchants, écrivent de nouvelles fonctionnalités), soit continuer à écrire des béquilles et à patcher des bugs, qui fuient en torrents.

Même si ce message s'adresse principalement à Peter, je vous demande de l'écrire sans argot, afin de bien comprendre vos messages, dans un langage accessible à l'élève de 1ère année d'école de programmation, puisque le sujet s'adresse aux débutants à partir de zéro.

Salutations, Vladimir.

Raison: