À propos du style de codage - page 2
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
Ici, vous devez choisir entre deux choses :
1) La facilité d'écriture et la lisibilité du code.
2) La vitesse d'exécution du programme.
Personnellement, j'ai toujours préféré la deuxième option, j'essaie donc de déclarer toutes les variables globalement et, si possible, de ne pas utiliser de fonctions (j'ai remarqué son effet sur la vitesse de calcul il y a longtemps). Il faut savoir que le conseiller expert fonctionne sur votre ordinateur 24 heures sur 24, qu'il a parfois besoin d'être optimisé et ainsi de suite. Par conséquent, la rapidité des calculs et la faible consommation de ressources sont très importantes.
Et maintenant, regardons de l'extérieur les différents langages de programmation. Par exemple, le Basic est facile à coder et à lire, mais la vitesse de calcul... Comparons maintenant le C++ avec celui-ci. Ici, les pôles ont déjà changé - il est plus difficile de coder (la lisibilité du code s'est dégradée) mais la vitesse de calcul a fortement augmenté. Et si vous prenez l'Assembleur, le code est presque illisible.
Par ailleurs, il est étrange qu'un programme écrit dans le même langage réponde également à ces critères et qu'il faille choisir entre la lisibilité du code et la vitesse d'exécution (bien qu'il n'y ait rien d'étrange, déclarer une variable - cela prend du temps ; appeler une fonction et lui passer des paramètres - cela prend du temps). Mais c'est un fait, qui, soit dit en passant, a été remarqué non seulement dans mql4...
Je préfère la première solution - peut-être parce que dans MQL4 je n'ai pas encore rencontré de cas où mes calculs sont si vastes que je dois choisir entre la lisibilité et la rapidité. Je ne joue pas avec les ticks, donc je n'ai pas besoin d'une vitesse de calcul folle.
D'autre part, il est difficile d'imaginer une EA que je ne doive pas modifier par la suite.
Je ne joue pas les tiques.
Ici, certaines caractéristiques commencent à apparaître. Je suis tout à fait d'accord - si vous jouez aux prix d'ouverture, alors l'architecture du programme doit changer. Par exemple, lorsque vous jouez aux prix d'ouverture, il n'est pas utile de déclarer des variables au niveau global et de les garder en mémoire jusqu'à l'apparition de la prochaine barre.
Le style de codage d'un programme doit être adapté à l'usage auquel il est destiné. Bien que les règles de codage soient les mêmes partout (fonctions, variables, etc.), la fréquence et le style d'utilisation de ces règles dans le code du programme dépendent des tâches finales spécifiques - pour quels calculs le programme sera utilisé. Chaque cas d'utilisation des règles de codage nécessite une approche différente.
fortement recommandé : http://astyle.sourceforge.net/ est un formateur de texte C, mais fait un excellent travail avec MQ4.
une seule commande : AStyle.exe -b -t -p before.mq4 transforme le texte "emballé" en bonbon.
Un utilitaire similaire a été proposé ici il y a longtemps par les propriétaires du forum, soit ici, soit sur metaquotes. Mais maintenant vous n'avez plus besoin de le chercher, merci Sergey. Et le style de conception est le même que celui que je préfère moi-même.
À un moment donné, je me suis demandé "quel style de programmation choisir". Comme j'avais peu d'expérience, j'ai résolu le problème simplement en ouvrant le code source de FreeBSD et en regardant de près le style que les programmeurs de la vieille école utilisaient. À l'époque, certaines choses me semblaient peu pratiques, mais je comprends maintenant pourquoi ils ont choisi ces solutions.
Donc, voici les règles selon lesquelles j'écris :
int main()
{
int sum;
for(int i=0;i<100;i++){
sum+=i;
Print("Число равно:", i);
}
return(0);
}
1. Dans les fonctions, je donne toujours des lignes séparées pour les accolades. Dans les boucles/conditions, je mets la première accolade sur la première ligne.
2. Je déteste le style très courant qui consiste à mettre des accolades de cette façon :
//+------------------------------------------------------------------+
//| expert start function |
//+------------------------------------------------------------------+
int start()
{
//----
//----
return(0);
}
//+------------------------------------------------------------------+
Commentaires //---- - Je ne le comprends pas du tout.
3. J'essaie de déclarer une variable pour les itérations dans la boucle elle-même.
4. J'aime utiliser des fonctions, j'essaie de diviser un programme en plusieurs parties. Mais il n'y a pas de contrainte rigide de 20 lignes par fonction. Je pense qu'une fonction doit accomplir une tâche locale. Les tâches sont parfois importantes, parfois moins importantes, et la fonction est donc différente.
5. J'utilise des fonctions dans une fonction :
res=OrderSend(Symbol(),OP_BUY,GetVolume(GetPrice(OP_BUY),GetStopLossLevel(GetPrice(OP_BUY))),GetPrice(OP_BUY),3,GetStopLossLevel(GetPrice(OP_BUY)),GetTakeProfitLevel(GetPrice(OP_BUY)),"",GetMagicNumber(OP_BUY),0,Blue);
6. J'utilise la fonction timing() :
void Timing()
{
//Здесь вызываем функции которые необходимо вызывать каждый тик
//...
//Здесь вызываем функции которые необходимо вызывать каждую минуту
if(IsNewMinute()==true){
}
//Здесь вызываем вункции которые достаточно вызывать каждый новый бар
if(IsNewBar()==true){
CheckForClosed();
CheckForOpen();
}
//Здесь вызываем функции которые необходимо вызывать каждый новый день, например функцию для расчета свопов
if(IsNewDay()==true){
}
}
Comme vous pouvez le constater, même avec la méthode de modélisation par tic, tout le bloc de calculs n'est pas défini à chaque tic, mais n'est appelé que lorsqu'il est vraiment nécessaire.
7. Je ne sais pas pourquoi, mais j'utilise presque toujours la boucle for() au lieu de while().
8. Je déteste utiliser des conditions imbriquées :
if(param1==1){
if(param2==2){
if(param3==3){
if(param4==4){
if(param5==5){
Print("Наконец-то дошли!");
}
}
}
}
}
J'utilise plutôt un code comme celui-ci :
if(param1!=1)return;
if(param2!=2)return;
...
if(param5!=5)return;
Print("Наконец-то дошли!");
if(param1!=1)return;
if(param2!=2)return;
...
if(param5!=5)return;
Print("Наконец-то дошли!");
En fait, il s'agit d'un code normal qui effectue les mêmes calculs que la construction if imbriquée. Mais j'ai entendu dire quelque part que le retour dans la fonction devait être un. Probablement, c'est fait pour ne pas s'y mêler. Je ne suis pas strictement cette règle.
Pour le reste, mon approche est très proche de la vôtre, C-4, à quelques détails près.
2. Je déteste le style très courant qui consiste à mettre des bretelles comme ça :
//+------------------------------------------------------------------+
//| expert start function |
//+------------------------------------------------------------------+
int start()
{
//----
//----
return(0);
}
//+------------------------------------------------------------------+
Commentaires //---- - Je ne le comprends pas du tout.
Pour ma part, je préfère ce style : vous n'avez pas à chercher les accolades à la fin d'une ligne. De nombreuses personnes perdent des accolades pour cette même raison (oubli de mettre une parenthèse fermante), ou au contraire, elles font des accolades fermantes supplémentaires. Mais en général, c'est une question de goût - chacun a une écriture différente sur le papier. Et chacun écrit ses notes différemment (quelqu'un fait une note de bas de page, quelqu'un souligne, quelqu'un indente) - l'essentiel pour l'auteur du carnet était de percevoir facilement les informations d'un coup d'œil. La syntaxe du langage vous permet de placer des accolades n'importe où, même sur une seule ligne. Mais pour une raison quelconque, personne ne ferme les accolades comme ça :
C'est pourquoi je n'économise pas d'espace pour une ligne de code séparée - toutes les parenthèses (ouvrantes et fermantes) sont à gauche les unes des autres (avec des retraits pour chaque bloc fermé suivant, style chevron) et d'un seul coup d'œil, vous pouvez estimer le début et la fin d'un opérateur composé (bloc), quelle que soit l'intelligence et la sophistication de la partie du programme. :)--------
Après tout, les parenthèses ne sont utilisées que pour désigner un opérateur composé (bloc) et non pour désigner le corps de la boucle. Je n'utilise pas de parenthèses lorsque l'opérateur n'est pas composé :Et si vous sélectionnez un opérateur composé avec une parenthèse ouvrante quelque part à droite, mais que vous mettez des parenthèses fermantes à gauche, alors
---------------
Comment coder, où mettre les parenthèses, etc. - est une question de goût pour chacun. L'essentiel est que le programme soit lisible, sans erreur, ne charge pas le système (l'algorithme doit être optimal) et réponde aux critères pour lesquels il est écrit.
Un outil similaire a été proposé ici par les propriétaires de forums il y a longtemps - soit ici, soit sur metaquotes. Mais maintenant, vous n'avez plus besoin de le chercher. Et le style de conception est le même, comme je le préfère.
Oui, il y en a un. :)
Pour le nettoyage du code, j'utilise MetaQuotes Styler à partir de deux fichiers que vous pouvez télécharger à partir de ce lien et placer dans le répertoire /Windows/System32.
Vous pouvez lancer le styler par la commande :
mqstyler.exe /file:nomdefichier.mq4
mqstyler.exe /file : "nom de fichier long avec espaces.mq4" (S'il y a des espaces dans le nom)
Personnellement, je prends Visual Studio (VC++), j'y copie le code MQL et je le formate selon la convention Microsoft, sans outils. En tant qu'éditeur de code, VS est également plus cool (pliage de code ?). Il est peut-être possible de visser une commande de compilation, mais je ne l'ai pas encore essayé.