Projet du conseiller - page 2

Nouveau commentaire
 
Vasiliy Sokolov:

Réarranger les parenthèses n'enlève rien au désordre. Avant de donner des conseils, amenez au moins votre niveau à la moyenne.

Qu'est-ce qui ne va pas avec mon niveau ?

 
STARIJ:

Le commentaire doit occuper la moitié du texte du programme.

J'écris même certaines choses - d'abord un long commentaire "ce qui devrait se passer ici", puis entre les deux le code qui l'implémente :-) Au fait, je conseille cette approche aux débutants également
 
Maxim Kuznetsov:
Il y a des choses que j'écris - d'abord un long commentaire "ce qui devrait être là", et ensuite le code qui l'implémente :-) D'ailleurs, je conseille une telle approche aux débutants, aussi
D'abord un stub pour la fonction avec la description de ce qu'elle va faire et le retour (quelque chose). Ensuite, le code
 
Vitaly Muzichenko:

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 ils prennent deux fois moins de place.


Commentez le code tout le temps, ce dont ce morceau de code est responsable, ce n'est pas difficile, et maintenant vous saurez toujours ce qu'est le code, et réduire le temps pour l'étudier.


Vitaly, j'ai bien compris, vous avez un écran d'ordinateur portable de 12 pouces ?

Je me souviens qu'à l'époque, au CV-1420 avec écran alphanumérique 24 lignes x 80 caractères, aussi, on essayait d'économiser de l'espace ;)) Maintenant, j'essaie de l'écrire de façon à ce qu'il soit plus facile à comprendre.

 
Vitaly Muzichenko:

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 ils prennent deux fois moins de place.


Commenter le code tout le temps, ce dont ce morceau de code est responsable, ce n'est pas difficile, et ici à la finalisation saura toujours ce que le code, et de réduire le temps pour l'étudier

Et puis, regardez ce à quoi font référence ces 4 crochets en bas. C'est un très mauvais codestyle. En général, MS a le meilleur, et le fait que MQ professe le style K&R n'est pas une raison pour l'imiter. L'époque des cartes perforées et des écrans 80x24 est révolue.

void CloseOrders(int cmd) {
 for(int i=OrdersTotal()-1;i>=0;i--) {
  if(OrderSelect(i,SELECT_BY_POS)) {
   if(OrderSymbol()==Symbol() && OrderMagicNumber()==Magic) {
    if(OrderType()==OP_BUY && cmd==OP_BUY) {
     if(!OrderClose(OrderTicket(),OrderLots(),Bid,Slippage,Blue)) Print("Order BUY not close! Error = ",GetLastError());
    }
     if(OrderType()==OP_SELL && cmd==OP_SELL) {
      if(!OrderClose(OrderTicket(),OrderLots(),Ask,Slippage,Red)) Print("Order SELL not close! Error = ",GetLastError());
    }
}}}}
Vasiliy Sokolov:
Eh bien, alors 90% du code sont des commentaires. De plus, il faut qu'il y ait le plus possible de code dénué de sens et mal lisible, afin qu'il soit possible de mettre plus de commentaires !

Mais quand je serai vieux, je pourrai publier les commentaires sous la forme d'un livre "Forex et moi" )))). Non, je préfère "Moi et Forex".

 
Alexey Volchanskiy:

Et ensuite, choisissez ce à quoi font référence ces quatre crochets en bas. C'est un très mauvais codestyle. En général, MS a le meilleur, et le fait que MQ professe le style K&R n'est pas une raison pour l'imiter. L'époque des cartes perforées et des écrans 80x24 est révolue.


Mais quand je serai vieux, je pourrai publier les commentaires sous la forme d'un livre "Forex et moi" )))). Non, je préfère "Moi et Forex".

Écran de travail 27".

Je ne vais pas le relire, mais 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.

 
Vitaly Muzichenko:

É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" ?

Le dossier où ils reposent est ouvert une fois tous les trois cents ans de la même manière.

Et quand il s'ouvrira - allez le trouver dans un tas }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} ce qui est quoi.

Pourquoi écrire un piège pour vous-même si vous l'avez écrit, testé et envoyé à une bibliothèque ou à une classe pour le stocker ? C'est tout. Et quand vous avez besoin de vous rafraîchir la mémoire (peut-être, vous avez besoin de faire quelque chose sur la base de celui-ci, peu importe... vous avez besoin d'ajouter quelque chose ) - vous vous asseyez simplement et déplacez les parenthèses...

 
Vitaly Muzichenko:

É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 plateforme 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 tiré de kodobase.

Vitaly, la première version de votre fonction montre clairement quelle parenthèse fermante se réfère à quelle parenthèse ouvrante, tandis que la deuxième version vous casse les yeux à chercher une paire...

En général, les fonctions personnalisées ne sont pas si grandes qu'elles ne peuvent pas tenir sur l'écran. Et la façon dont les parenthèses sont disposées dans l'EA compilé n'a aucune importance.

 
Artyom Trishkin:

Le dossier où ils reposent est également ouvert une fois tous les trois cents ans.

Mais lorsqu'il s'ouvrira, vous devrez fouiller dans la pile }}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}} pour savoir ce qu'il contient.

Pourquoi écrire un piège pour vous-même, si vous l'écrivez, testez-le et envoyez-le à la bibliothèque ou à la classe pour qu'il soit stocké. C'est tout. Et lorsqu'il est nécessaire de se rafraîchir la mémoire (et peut-être de faire quelque chose sur la base de celle-ci, on ne sait jamais...) - il suffit de s'asseoir et de déplacer les parenthèses...

Non, je n'ai rien dans le fichier, je ne suis pas gourmand et je partage des programmes avec des connaissances et très souvent, et au lieu d'envoyer des archives, j'envoie juste un fichier.

Toutes les fonctions se trouvent en bas, mais le code exécutif est toujours bien écrit et commenté, même un enfant peut le comprendre.

 
Gregory Kovalenko:
Bonjour.
Lorsque la quantité de code augmente, elle devient parfois difficile et confuse.
J'ai vu du code d'EA avec un nombre énorme de lignes de code, je me demande comment sont conçus les EA complexes, peut-être existe-t-il des outils ou des techniques pour traiter des algorithmes aussi complexes ?

J'ai plusieurs milliers de lignes de code dans un EA. (Ils sont automatiquement inclus dans les inclusions).

En fait, un EA consiste en un modèle de classe CExpert, qui possède des fonctions OnInit, OnTick, etc. Dans le modèle de connexion de l'EA, toutes les fonctions globales - événements - appellent les fonctions correspondantes de ce type d'objet.

Pendant l'initialisation - CExpert demande via la fonction globale prédéfinie "EA parts factory", qui sait comment créer tout le nécessaire pour le travail.

Le conseiller expert lui-même se compose de cinq lignes. L'objet de l'usine de pièces de l'EA lui-même est déclaré dans ce fichier, et les inclusions sont incluses.

Personnellement, j'aime beaucoup l'approche OOP, avec la division des interfaces virtuelles et de l'implémentation. Tout d'abord, nous décrivons le fichier d'interface - une classe abstraite dans laquelle toutes les fonctions sont virtuelles et égales à zéro. Cette classe définit le "protocole d'interaction". Ensuite, nous en héritons de véritables classes dans lesquelles toutes ces fonctions sont entièrement implémentées (parfois, nous avons toute une hiérarchie de classes, lorsque la description des fonctions est distribuée "par niveau").

Cette approche permet de séparer les entités, ce qui facilite grandement le soutien de l'ensemble du projet, ainsi que la réutilisation des classes.

1234567
Nouveau commentaire
Raison: