Caractéristiques du langage mql4, subtilités et techniques - page 11

Nouveau commentaire
 
Ihor Herasko:

Dans de nombreuses entreprises de logiciels, un tel code leur ferait perdre tous leurs doigts. La première chose à faire, toujours et partout, est d'éviter les "lectures inutiles". Par exemple, si vous utilisez une condition lors de la saisie d'une fonction :

alors il est recommandé d'écrire :

Cette approche est très utile lorsqu'elle n'est assortie d'aucune condition.

Une fois de plus, ce sera un casse-tête. Après tout, personne n'a vérifié ce que la fonction OrderType() a renvoyé. Ou peut-être que ça a donné -1 ou 6 ? Il s'agit d'un exemple d'utilisation des propriétés du compilateur dont il faut toujours se méfier. Vous citez vous-même de nombreux exemples de code multiplateforme. Alors pourquoi vous en écarter dans ce cas ? Un nouveau compilateur MQ sortira et ce code ne fonctionnera plus correctement.

Qu'est-ce que les sociétés de logiciels ont à voir avec ce dont nous discutons ! Le code ne cessera pas de fonctionner, pas besoin de cospirologie ici.

C'est la même chose pour la poursuite. Code comme :

est plus difficile à lire que :

Et pourtant, l'efficacité de l'exécution est la même dans les deux cas.

Dans ce cas, un code d'une ligne est plus facile à lire qu'un code de six lignes. De plus, elle est plus logique car elle n'est en aucun cas tenue d'être à l'intérieur d'une boucle. C'est-à-dire que vous pouvez copier-coller le premier cas sans vous soucier du second.

 
fxsaber:

L'exemple Lots[] ci-dessus est un trésor qui montre comment le code peut être à la fois super-laconique et totalement compréhensible.

C'est vous qui trouvez le code compréhensible. Mais quelqu'un qui ne regarde que la documentation et voit votre code se demandera pourquoi la taille du tableau est de 8, alors que la documentation ne contient que 6 types d'ordre.

Et personnellement, je trouve aussi plus facile de lire les conditions si elles sont séparées séparément, c'est-à-dire comme ceci :

if (!OrderSelect(i, SELECT_BY_POS))
   continue;

if (OrderSymbol() != Symbol())
   continue;

if (OrderMagicNumber() != m_nMagicNumber)
   continue;

Je suis aussi plus à l'aise que comme ça :

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)
{
}

Mais je pense que c'est une question de goût et d'habitude. Personne n'a besoin d'imposer ou de prouver quoi que ce soit.

D'un autre côté, je suis d'accord avec vous :

MT4-история торгов отсортирована по времени закрытия и это правило меняться не будет.

Et je pense que c'est logique, et je ne me souviens pas d'autres fois.

 
Alexey Kozitsyn:

Pour vous, le code est compréhensible. Mais quelqu'un qui vient de parcourir la documentation et de voir votre code se demandera immédiatement pourquoi le tableau a une taille de 8, alors que les types d'ordre dans la documentation ne sont que de 6.

Vous voyez donc comment un simple code génère les bonnes questions dans l'esprit des gens ! Et après cela, faut-il faire confiance à tout ce qui est écrit dans la documentation ?

 
fxsaber:

Et après ça, faut-il faire confiance à tout ce qui se trouve dans la Documentation ?

Vous devriez, c'est un principe de base de la programmationRTFM.

RTFM
  • lurkmore.to
RTFM (изначально сокр. от англ. read the following manual, «обратитесь к прилагаемому руководству») — типичный ответ службы поддержки на вопрос пользователя, обычно сопровождающийся номером или названием этого руководства.
 
Igor Makanu:

devrait, c'est un principe de base de la programmationRTFM.

La réalité contredit ce principe.

 
fxsaber:

Qu'est-ce que les sociétés de logiciels ont à voir avec ce dont nous discutons !

Eh bien, qui d'autre pouvez-vous citer comme autorité ?

Le code ne cessera pas de fonctionner, pas besoin de cospirologie ici.

Oui, dans MT4 avec une probabilité de 99%, c'est le cas, car MT4 est presque enterré. Mais essayez de réaliser un tel tour de passe-passe sur plusieurs plates-formes et vous vous heurtez immédiatement à un défaut qui disparaît et entraîne une erreur fatale.

Dans ce cas, le code d'une ligne est plus facile à lire que le code de six lignes. De plus, elle est plus logique car elle n'est pas liée à la nécessité d'être à l'intérieur d'une boucle de quelque façon que ce soit. C'est-à-dire que le premier cas peut être facilement copié, le second non.

Si nous parlons d'un cas particulier, cela peut être vrai, car le code donné est presque standard pour chaque EA. Mais si vous prenez quelque chose de plus compliqué, il est difficile de le lire lorsqu'il est écrit en une seule ligne.

Pourquoi écouter des malédictions venues de l'espace de la part de quelqu'un qui travaille avec votre code ? ))

 
Ihor Herasko:

Eh bien, qui d'autre pouvez-vous citer comme autorité ?

Il est étrange que la notion d'autorité soit abordée ici.

Oui, dans MT4 il y a une probabilité de 99% que ce soit le cas, car MT4 est presque enterré. Mais si vous essayez de réaliser un tel tour de force sur plusieurs plates-formes, vous vous heurtez immédiatement à un défaut qui disparaît et entraîne une erreur fatale.

L'écriture dans MT5 est identique.

Si nous parlons d'un cas particulier, il peut en être ainsi car le code donné est presque standard pour chaque EA. Mais si vous prenez quelque chose de plus compliqué, il est difficile de le lire lorsqu'il est écrit en une seule ligne.

Et il existe aussi des constructions si -> autre si -> autre. Je ne comprends pas pourquoi une expression bool dans un opérateur conditionnel doit être donnée sous la forme la plus primitive.

 
Alexey Kozitsyn:

Pour vous, le code est compréhensible. Mais quelqu'un qui vient de parcourir la documentation et de voir votre code se demandera immédiatement pourquoi le tableau est de taille 8, alors que les types d'ordre dans la documentation ne sont que 6.

Et personnellement, je trouve aussi plus facile de lire les conditions si elles sont séparées séparément, c'est-à-dire comme ceci :

Je suis aussi plus à l'aise que comme ça :

Mais je pense que c'est une question de goût et d'habitude. Personne n'a besoin d'imposer ou de prouver quoi que ce soit.

D'un autre côté, je suis d'accord avec vous :

Et je pense que c'est logique, et je ne me souviens pas d'autres fois.

Ce sont les mots clés.

Personnellement, je suis gêné par l'orthographe de continue.

A quoi servent-ils ? ? ??? Si vous lisez 

if (OrderSelect(i, SELECT_BY_POS) && OrderSymbol() == Symbol() && OrderMagicNumber() == m_nMagicNumber)

Tout se lit en russe :

Si la commande est sélectionnée et que le symbole de la commande est "le nôtre" et que le magicien est également le nôtre... alors nous faisons tout entre accolades.

Mais ça n'a pas l'air très russe :

Si le mandat n'est pas sélectionné, allez vous faire voir...

Si le symbole du mandat n'est pas le nôtre, allez vous faire voir...

et ainsi de suite.

Combien de fois devrons-nous nous envoyer là....................

Apparemment, cela avait un sens dans mql3. C'était un moyen de réduire le temps de vérification de l'état. Ensuite, toutes les conditions sont vérifiées du début à la fin. Cependant, la situation a été résolue depuis longtemps : si le contrôle rencontre une condition non remplie, les contrôles ultérieurs s'arrêtent. Et toutes ces astuces n'ont absolument aucun sens.

 
Alexey Viktorov:

Ce sont les mots clés.

Personnellement, je suis ennuyé par l'orthographe de continuer à tout faire.

A quoi servent-ils ? ? ??? Si vous lisez

tout se lit en russe :

Si la commande est sélectionnée et que le symbole de la commande est "le nôtre" et que le magicien est également le nôtre... alors nous faisons tout entre accolades.

Mais ça n'a pas l'air très russe :

Si le mandat n'est pas sélectionné, allez vous faire voir...

Si le symbole du mandat n'est pas le nôtre, allez vous faire voir...

et ainsi de suite.

Combien de fois devons-nous nous envoyer là....................

Ça devait avoir un sens dans mql3. C'était un moyen de réduire le temps de vérification d'une condition. À cette époque, toutes les conditions étaient vérifiées du début à la fin. Toutefois, la situation a été résolue depuis longtemps : si le contrôle est tombé sur une condition non remplie, les contrôles ultérieurs s'arrêtent. Et toutes ces astuces n'ont absolument aucun sens.

Vous avez convenu vous-même que c'est une question d'habitude. Moi, par exemple, je suis gêné par les imbrications inutiles, je les supprime toujours avec return, continue. Et au lieu de "aller en enfer", il est facile de s'habituer à lire "les conditions 1 et 2 sont remplies" :

if(!condition1 || !condition2)
   continue;
 
Vladislav Boyko:

Par exemple, je suis gêné par les imbrications inutiles, je les supprime toujours en utilisant return, continue

Je suis irrité par la"négation booléenne NOT( !)", non seulement elle prend un coût de CTs, mais la lecture d'une expression logique se transforme en lecture "à l'envers" ;)))

Je renvoie toujours "true" dans les fonctions bool comme la réponse la plus attendue, par exemple : je vérifie la disponibilité du serveur de cette façon :

bool ServerDisable(int count=10){
   for(int i=0;i<count;i++){
      if(IsConnected())
         if(IsTradeAllowed())
            if(!IsTradeContextBusy()){RefreshRates(); return(false);}
      Sleep(157);
   }
   Print(__FUNCTION__," Торговый сервер не отвечает");
return(true);}

Je le trouve assez lisible et logique :

if(ServerDisable()) return;

si le serveur est occupé - exit, je l'utilise généralement dans les fonctions commerciales, il n'est pas nécessaire d'ennuyer le serveur avec des demandes parce qu'il est occupé.

comme on dit - c'est une question de goût, mais comme vous le savez : les goûts diffèrent ))))

1...456789101112131415161718...35
Nouveau commentaire