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
Et ensuite, il faut chercher à quoi correspondent ces quatre crochets en bas.
D'ailleurs, cela me rend très nerveux lorsque l'imbrication est supérieure à deux niveaux. J'essaie de ne jamais écrire de cette façon, en répartissant le code sur les fonctions.
Et même lorsqu'il y a deux niveaux d'imbrication, assurez-vous d'écrire des commentaires après chaque crochet fermant - quel bloc il enterre (disons, un en-tête de boucle en double).
En ce qui concerne le style, voici mon code pour sélectionnerune position historique pour MT5 (par un magicien, un symbole, avec une plage de dates spécifiée) :
La classe historique elle-même est un descendant de l'interface abstraite CTradeHistoryI :
En sélectionnant l'historique requis - vous pouvez recalculer ses composants (positions pour MT5 ou ordres pour MT4), et obtenir une interface à n'importe quel composant comme une interface abstraite :
Pour MT4 - il y a des classes d'historique correspondantes également héritées de ces interfaces - ainsi, en même temps, la multiplateforme est fournie - un EA n'a pas besoin de trouver où il travaille, tout le travail avec l'historique est fait par les interfaces abstraites.
N'écrivez pas de fonctions qui sont toujours constantes et ne changent jamais dans ce style
Rédigez-les de manière concise, personne ne les regarde jamais de toute façon, et elles prennent deux fois moins de lignes.
Puisque ces fonctions ne changent pas, pourquoi avoir mis un tas de crochets inutiles à cet endroit ? Enlevez-les, et tout sera compressé. Parce que votre exemple est absurde : vous avez vous-même brouillé le code et vous inventez ensuite des béquilles pour le réduire.
Je suis d'accord, vous pouvez couper 3 lignes de plus, et raccourcir le code, mais le but n'était pas de mettre le code à utiliser, il n'est en fait même pas le mien, mais de raccourcir, et de telles fonctions peuvent être mis cinq dans un écran, pas un. Ensuite, les programmes sont plus faciles à lire et vous n'avez pas besoin de faire défiler 150 fois les pages. Et le poids du dossier diminue.
Beau travail, j'aime bien, mais je n'aime pas la POO et j'essaie de m'en passer. Je n'aime pas les processeurs avec division des threads (comme 4 cœurs et 8 threads). Il doit être clair que la division et toute virtualisation est une perte de performance et une perte de temps machine pour son implémentation, que ce soit la division des threads dans le noyau ou la virtualisation des fonctions dans le code.
Je suis d'accord, vous pouvez couper 3 lignes de plus, et raccourcir le code, mais le but n'était pas de mettre le code à utiliser, il n'est en fait même pas le mien, mais de raccourcir, et de telles fonctions peuvent être mis cinq dans un écran, pas un. Ensuite, les programmes sont plus faciles à lire et vous n'avez pas besoin de faire défiler 150 fois les pages. Et le poids du dossier est réduit.
Sincèrement.
Écran de travail de 27 pouces
Je ne vais pas le relire, je vais juste le citer :"N'écrivez pas de fonctions qui sont toujours constantes et ne changent jamais dans ce style"
Pourquoi s'acharner sur une fonction qui n'est écrite qu'une fois lors de la sortie de la plate-forme et qui ne changera jamais à l'avenir ? Modifiez-vous souvent le code dans les fonctions pour obtenir la taille du lot, le nombre d'ordres et les caractéristiques ? Alors pourquoi l'étirer sur 3 écrans d'un moniteur 32" ?
P.S. Le code ci-joint est forgé à partir de kodobase.
Question de comptoir ;))) J'ai de telles fonctions dans le fichier MyFunc.mqh, je ne vois pas le moindre intérêt à le compresser. Pourquoi, pour économiser 10-20 Ko sur le disque ? Et franchement, ce genre de flux codé me rend malade ;))
Question de comptoir ;))) J'ai de telles fonctions dans le fichier MyFunc.mqh, je ne vois pas le moindre intérêt à le compresser. Pourquoi, pour économiser 10-20 Ko sur le disque ? Pour être honnête, ce codestream me rend malade ;)).
Pour ma part, le code doit être clair, court, rapide à travailler et doit fonctionner dans toutes les conditions sans erreur.
Sincèrement.
Question de comptoir ;))) J'ai de telles fonctions dans le fichier MyFunc.mqh, je ne vois pas le moindre intérêt à le compresser. Pourquoi, pour économiser 10-20 Ko sur le disque ? Et franchement, un tel flux de données me rend malade ;))
Donc, comptez : 1000 EAs x 10 Kb = 10 Mb - il faut déjà penser à économiser ;))
Question de comptoir ;))) J'ai de telles fonctions dans le fichier MyFunc.mqh, je ne vois pas le moindre intérêt à le compresser. Pourquoi, pour économiser 10-20 Ko sur le disque ? Et franchement, ce genre de flux codé me rend malade;))
Moi aussi, mais il y a longtemps que je suis arrivé à la conclusion que le code doit être compact dans des endroits où on ne le regarde jamais, où il n'est jamais corrigé et ne le sera jamais.
La dispersion du code utilisateur avec tous ces emplacements est un casse-tête supplémentaire, car vous devrez glisser et déposer les fichiers dans différents terminaux ou les partager. Bien sûr, vous pouvez transférer les includniks dans tous les terminaux, mais si vous modifiez ou ajoutez quelque chose dans un terminal, alors tous les includniks doivent être remplacés par un nouveau.
Les conseillers experts et les indicateurs sont si petits qu'il n'y a aucun intérêt à les éloigner du corps du programme. Pour être plus correct, ils ne sont pas petits, ils sont en fichier unique, ce n'est pas comme un site de 10 000 pages où vous ne pouvez pas vous passer des classes et des inludes. De plus, il existe maintenant des structures, et elles sont suffisantes pour écrire un code compact et 100% exploitable.
D'ailleurs, cela me rend très nerveux lorsque l'imbrication se fait sur plus de deux niveaux. J'essaie de ne jamais l'écrire de cette façon, en répartissant le code sur les fonctions.
Et même lorsqu'il y a deux niveaux d'imbrication, veillez à écrire des commentaires après chaque parenthèse fermante, pour indiquer quel bloc elle enterre (par exemple, un en-tête de boucle en double).
En ce qui concerne le style, voici mon code pour sélectionner uneposition historique pour MT5 (par magik spécifié, symbole, avec une plage de dates spécifiée) :
La classe historique elle-même est un descendant de l'interface abstraite CTradeHistoryI :
En sélectionnant l'historique requis - vous pouvez recalculer ses composants (positions pour MT5 ou ordres pour MT4), et obtenir une interface à n'importe quel composant comme une interface abstraite :
Pour MT4, il existe des classes d'historique correspondantes qui héritent également de ces interfaces - ainsi, en même temps, la multiplateforme est assurée - le conseiller expert n'a pas besoin de savoir où il travaille, tout le travail avec l'historique est effectué par le biais d'interfaces abstraites.
Cela a l'air bien, mais pouvons-nous également nous pencher sur TRACE_*** et ASSERT ?
Pour glisser et déposer un fichier vers un autre terminal, ou pour le partager, vous devez faire glisser non pas un seul fichier, mais plusieurs. Vous pouvez, bien sûr, transférer les inludes vers tous les terminaux, mais si vous modifiez ou ajoutez quelque chose dans un terminal, vous devez alors le remplacer par un nouveau dans tous les terminaux.