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

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 contre les conditions d'attachement.

Une fois de plus, c'est un casse-tête. Parce que personne n'a vérifié ce que la fonction OrderType() a retourné. Ou peut-être que ça a donné -1 ou 6 ? Il s'agit d'un exemple d'utilisation des propriétés du compilateur, ce dont il faut toujours se garder. 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.

Avec toujours la même situation. Code comme :

est plus difficile à lire que :

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

C'est une vraie déception :

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

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

if (OrderMagicNumber() != m_nMagicNumber)
   continue;
 
Vitaly Muzichenko:

C'est une vraie déception, n'est-ce pas ?

C'est quoi "tinny" ? Une ligne d'une superexpression - c'est ce qui est trivial. Les êtres humains ne sont pas des ordinateurs, et ils n'ont pas à traiter le reste de la condition. L'homme, contrairement à l'ordinateur, doit calculer l'expression entière jusqu'au bout, puis comprendre que sa première composante conduit à un résultat faux.

Dans une entrée, où tout est décomposé par des conditions simples, ce calcul est inutile : la première condition n'est pas remplie - parti.

Vous devez gagner du temps, pas des ficelles. Mais ils se battent juste pour la brièveté, qui est en fait un emballage des opérations et des conditions les unes dans les autres. Si seulement cet emballage vous permettait de réaliser un gain de productivité considérable, je pourrais le comprendre. Mais ce n'est pas le cas. La croissance maximale se situe dans les limites de l'erreur de mesure. Les gens sont préoccupés par l'économie de chaînes de caractères, mais ils ne pensent pas du tout à l'économie du temps passé à comprendre et à déboguer le code.

 
Ihor Herasko:

C'est quoi la boîte ? Une ligne de super-expression - c'est là que c'est difficile. Un humain n'est pas un ordinateur, il peut donc comprendre immédiatement qu'il n'est pas nécessaire de traiter le reste de la condition. L'homme, contrairement à l'ordinateur, doit calculer l'expression entière jusqu'au bout, puis comprendre que sa première composante conduit à un résultat faux.

Dans une entrée, où tout est décomposé par des conditions simples, ce calcul est inutile : la première condition n'est pas remplie - parti.

Vous devez gagner du temps, pas des ficelles. Mais ils se battent juste pour la brièveté, qui est en fait un emballage des opérations et des conditions les unes dans les autres. Si seulement cet emballage vous permettait de réaliser un gain de productivité considérable, je pourrais le comprendre. Mais ce n'est pas le cas. La croissance maximale se situe dans les limites de l'erreur de mesure. Les gens sont préoccupés par la sauvegarde des chaînes de caractères, mais ils ne pensent pas du tout à économiser le temps passé à comprendre et à déboguer le code.

Je n'appellerais pas cela une super-expression difficile à lire.

if(!OrderSelect(i, SELECT_BY_POS) || OrderSymbol() != Symbol() || OrderMagicNumber() != m_nMagicNumber)
   continue;

Oh, et le "cycle de calcul court" est un élément de base qui est "automatiquement" pris en compte lors de la lecture d'une condition sans qu'aucun effort mental ne soit nécessaire pour le faire.

Encore une fois, c'est une opinion purement subjective.

 
Vladislav Boyko:

Vous avez vous-même reconnu que c'est une question d'habitude.

Et je vais le répéter. Je n'encourage personne à changer ses habitudes et à chercher une différence de goût dans les feutres.

Igor Makanu:

Comme vous l'avez dit - c'est une question de goût, mais comme vous le savez : tous les feutres sont différents )))).

Les feutres ne sont différents que par leur couleur, ils ont le même goût.
 
Vladislav Boyko:

Je n'appellerais pas ça un superlatif difficile à lire.

Et il n'y a pas besoin d'appeler quoi que ce soit ici. Jusqu'à présent, mes adversaires (vous y compris) n'ont pas avancé un seul argument selon lequel cette expression est plus facile à lire que le découpage en lignes.

De ma part, cependant, pas moins de trois arguments ont été avancés :

  1. Une longue ligne ne rentre pas dans le champ de vision. Nécessite au moins une rotation minimale de la tête (ce qui augmente le temps de traitement). Une ligne courte et celle qui la suit ne demandent pas tant d'efforts.
  2. Dans une longue file, il est plus facile de faire une erreur et de ne pas la remarquer. Le fractionnement en lignes diminue la probabilité de ce type d'erreur.
  3. Une longue ligne est impossible à déboguer. Le fractionnement en chaînes de caractères est correct.
Pas de préférences subjectives. Tout est justifié par le sens pratique et rien de plus. Oui, certaines personnes peuvent trouver plus pratique de se gratter l'oreille gauche avec le talon droit, mais cela ne signifie pas que cette approche soit pratique. Dans la nature, tout est soumis à l'aspect pratique et ceux qui sont plus pratiques survivent.
 
Ihor Herasko:

Et il n'y a pas besoin de nommer quoi que ce soit ici. Jusqu'à présent, mes adversaires (vous y compris) n'ont pas avancé un seul argument selon lequel cette expression est plus facile à lire que le découpage en lignes.

De ma part, cependant, pas moins de trois arguments ont été avancés :

  1. Une longue ligne ne rentre pas dans le champ de vision. Nécessite au moins une rotation minimale de la tête (ce qui augmente le temps de traitement). Une ligne courte et celle qui la suit ne demandent pas tant d'efforts.
  2. Dans une longue file, il est plus facile de faire une erreur et de ne pas la remarquer. Le fractionnement en lignes diminue la probabilité de ce type d'erreur.
  3. Une longue ligne est impossible à déboguer. Le fractionnement en chaînes de caractères est correct.
Pas de préférences subjectives. Tout est justifié par le sens pratique et rien de plus. Oui, certaines personnes peuvent trouver plus pratique de se gratter l'oreille gauche avec le talon droit, mais cela ne signifie pas que cette approche soit pratique. Et dans la nature, tout est soumis à l'aspect pratique et ceux qui sont plus pratiques survivent.

Igor, si les yeux ne bougent pas dans les orbites et que tu dois tourner la tête, tu peux écrire comme ça :

if(OrderSelect(i, SELECT_BY_POS)
&& OrderSymbol() == _Symbol
&& OrderMagicNumber() == m_nMagicNumber)
 {
  // Делаем что надо...
 }

Et combien de petites lignes j'ai rencontrées avec des erreurs........... Apparemment, le nombre et la probabilité des erreurs ne dépendent pas de la longueur de la ligne.

On ne peut qu'être d'accord avec le débogage. Mais cette habitude s'est développée avant l'apparition du débogueur dans mql4 et tout le monde n'est pas capable de changer ses habitudes.

 
Alexey Viktorov:

Igor, si les yeux ne bougent pas dans les orbites et que tu dois tourner la tête, tu peux l'écrire comme ça :

Et combien de petites lignes j'ai rencontrées avec des erreurs........... Apparemment, le nombre et la probabilité des erreurs ne dépendent pas de la longueur de la ligne.

On ne peut qu'être d'accord avec le débogage. Mais l'habitude s'est développée avant le débogueur dans mql4 et tout le monde n'est pas capable de changer les habitudes.

Vous pouvez le faire de cette façon, mais avec ce style, pour voir un bloc de programme, vous devez faire défiler l'écran deux fois, ce qui est pire que de voir tout le code sur un seul écran. (Cela ne vous concerne pas, c'est juste un exemple).

 
fxsaber:

Malheureusement, ce mythe ne trouve aucun appui dans l'histoire du forum. De plus, les développeurs ont toujours clairement indiqué leur position selon laquelle de tels changements ne peuvent pas être effectués par principe.

Ça a existé. Le tri a eu un impact.

La discussion a probablement eu lieu sur l'ancien forum metatrader4.com (encore ouvert récemment, il est maintenant redirigé vers mql5.com).

 
Andrey Khatimlianskii:

C'était comme ça. Le triage a été affecté.

La discussion devait avoir lieu sur l'ancien forum metatrader4.com (encore ouvert récemment, mais redirigé maintenant vers mql5.com).

C'était, c'était. Comme maintenant avec le nombre d'ordres historiques, si vous définissez "Aujourd'hui", alors OrdersHistoryTotal() renverra le nombre d'ordres fermés qui ont été fermés aujourd'hui. Si l'onglet "Historique" ne montre pas d'ancienne commande, alors celle-ci n'est pas disponible, même par ticket.

 
Alexey Viktorov:

C'était, c'était. Comme maintenant avec le nombre d 'ordres historiques, si vous définissez "Aujourd'hui", OrdersHistoryTotal() retournera le nombre d'ordres clôturés aujourd'hui. Si l'onglet "Historique" ne montre pas d'ancienne commande, c'est qu'elle n'est pas disponible, même par ticket.

Il s'agit de trier. À l'époque, s'ils n'étaient pas triés par heure, vous ne pouviez pas trouver le dernier par index - c'était le dernier des triés.

Et maintenant, la profondeur de l'histoire ne dépend pas de l'onglet sélectionné ? À mon avis, c'est toujours le cas.

1...5678910111213141516171819...35
Nouveau commentaire