Auto-apprentissage du langage MQL5 à partir de zéro - page 48
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Alexei, tu plaisantes ? Oui, j'aimerais d'abord apprendre les bases !
Respectueusement, Vladimir.
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.
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.
Merci, Alexey, pour votre foi en moi. Tout ce que j'ai à faire, c'est de continuer à faire du bon travail !
Sincèrement, Vladimir.
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.
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.
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 :
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.
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.
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.
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.
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 :
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.