Better Programmer (Partie 01): Vous devez arrêter de faire ces 5 choses pour devenir un programmeur MQL5 performant

Introduction

"L'esprit de l'homme, une fois étiré par une nouvelle idée, ne retrouve jamais ses dimensions d'origine."
— Oliver Wendell Holmes

Pour que nous devenions de meilleurs programmeurs, nous devons non seulement apprendre à coder 24h/24 et 7j/7, mais nous devons également connaître les meilleures pratiques, voire apprendre à coder. Apprendre à apprendre le code ainsi que les meilleures pratiques à appliquer est crucial pour tous ceux qui ont besoin d'avoir une carrière de codage réussie. En connaissant le comment et le pourquoi, nous prenons conscience de ce que nous faisons, ce qui augmente notre capacité à nous souvenir et nous aide à améliorer notre code en général.

Les méthodes suivantes sont les méthodes éprouvées qui peuvent changer votre expérience de programmation et elles vous permettent de le faire, presque du jour au lendemain, si vous appliquez attentivement tout ce que vous êtes sur le point de lire dans cet article.

01 : Arrêtez les habitudes de copier-coller à l'aveugle

"Le plaisir le plus noble est la joie de comprendre." 
— Léonard de Vinci

C'est la plus grande habitude des débutants et parfois même des programmeurs expérimentés le font. Je me souviens que lorsque j'ai commencé à programmer en 2019, j'étais la plupart du temps sur le forum à la recherche de ce "code qui fonctionne". Je ne prêtais pas beaucoup d'attention à ce qui était expliqué à chaque fois que je faisais une recherche sur une certaine question ; tout ce que je cherchais, c'était ce commentaire auquel quelqu'un aurait répondu comme "Merci, ça marche maintenant" ou tout autre commentaire que quelqu'un aurait trouvé utile (surtout la personne qui a posé la question en premier lieu dans le forum )… Inutile de dire ce que j'ai fait une fois que j'ai trouvé ce morceau de code qui fonctionne !!!

C'est embarrassant maintenant quand je me rends compte que j'ai déclaré une fois que le graphique de bibliothèque standard ne fonctionnait pas

  

Maintenant, je sais ce qui n'a pas fonctionné à ce moment-là - c'était moi parce que même le code lui-même a été copié d'un endroit dont je ne me souviens pas. Mon propos ici est le suivant :

Assurez-vous de comprendre ce que vous faites. Ne copiez-collez pas aveuglément le code du forum juste pour faire avancer les choses et pour réparer les choses rapidement

La plupart du temps, la façon dont de nombreux développeurs expérimentés répondent aux personnes sur le forum est difficile à suivre pour les personnes ayant cette habitude, car ils ne répondent qu'en fournissant un lien vers la documentation MQL5, sur un certain sujet, sans parler des fonctionnalités automatiques sur ce site Web qui fournissent des liens connexes à un problème spécifique. La raison derrière cela est que la plupart des problèmes sont causés par une mauvaise compréhension des fondamentaux et des bases.

TOUJOURS : Recherchez la compréhension et non une solution !

Une fois que vous comprenez les fondamentaux, le codage devient naturel et automatique.

Les habitudes de copier-coller nuiront non seulement à votre réputation, mais vous causeront également plus de problèmes que de solutions.

02 : Abandonnez le piratage

Avant de vouloir résoudre le problème dans votre code, assurez-vous de savoir pourquoi vous rencontrez le problème. Le savoir vous aidera à poser de meilleures questions sur le forum plutôt que de faire glisser votre code en attendant un code en échange pour résoudre le problème causé par le fait que vous ne savez pas exactement quoi et pourquoi vous codez. Par exemple, moi sur l'image ci-dessus : tout d'abord, j'ai copié le code dans l'espoir de modifier le modèle de graphique, sans connaître et comprendre parfaitement le graphique de la bibliothèque standard. C'est pourquoi j'ai fini par dire que la bibliothèque ne fonctionnait pas.

Une fois que vous rencontrez un problème ou une erreur, assurez-vous de bien connaître la bibliothèque et le code que vous avez qui ne fonctionne pas. Il y a plusieurs façons de le faire sur MQL5, les deux principales étant

• La documentation MQL5
• Le Forum

Documentation MQL5 :

Heureusement pour nous, nous avons toute la documentation à portée de main et il n'est pas nécessaire d'être en ligne sur les moteurs de recherche. Les programmeurs professionnels le savent, mais pour les novices, voici où et comment y accéder très rapidement : ouvrez MetaEditor, puis allez dans la section Aide et cliquez sur l'option déroulante MQl5 Référence et voilà.

Forum MQL5 :

C'est le meilleur endroit pour apprendre et entendre ce que vous n'avez pas vu à travers votre propre code en partageant les problèmes que vous rencontrez avec d'autres développeurs. Mais ne commettez pas la même erreur que moi, NE COPIEZ PAS !

 "C'est le chemin de l'artisanat qui mène à la véritable compréhension et à la maîtrise."

Les noobs sont dans ce que j'appelle le CYCLE DES NOOBS

03 : Abandonnez le perfectionnisme

"Fait vaut mieux que parfait."
— Idée populaire dans la Silicon Valley

Je ne peux pas vous dire combien et combien de temps cela m'a empêché de partager des trucs. J'étais toujours à la recherche du Saint Graal pour pouvoir partager avec d'autres utilisateurs sur ce site Web. Il m'a fallu du temps pour réaliser que si j'avais quelque chose à partager, je devais le partager et ne pas être arrêté par ma propre pensée.

Qu'est-ce qui est mieux ?

Faire un indicateur, un Expert Advisor, une Bibliothèque ou un morceau de code dans les prochaines années, ou être prolifique et faire des centaines de résultats imparfaits en un an ?

Écrivez un code suffisamment bon pour vos collègues développeurs ou clients, pas un code parfait pour vous-même. Vous aurez toujours le temps et l'opportunité d'améliorer le code qui doit être amélioré ; dans d'autres cas, vous gagnerez du temps en expédiant le code plus rapidement.

Vous pouvez voir que cela s'applique à presque tout ce à quoi les programmeurs peuvent penser, chaque jour :

• Nos applications mobiles sont mises à jour 
• Les systèmes d'exploitation et logiciels de nos ordinateurs et téléphones sont mis à jour
• Même les langages de programmation tels que MQL5, Python et autres s'améliorent jour après jour 

Vous voyez, si même nos langages et frameworks de programmation sont mis à jour, vous savez probablement que s'améliorer au fil du temps n'est pas une mauvaise chose.

Sur MQL5.com, cela s'applique à peu près partout - vous pouvez penser à mettre à jour les programmes sur le marché.

Sur le forum, vous pouvez modifier le message du forum, supprimer ou simplement mettre à jour votre réponse et même votre propre commentaire c'est fou ! , haha

04 : Évitez d'écrire du code intelligent

"Le débogage est deux fois plus difficile que d'écrire du code en premier lieu. Par conséquent, si vous écrivez du code aussi intelligemment que possible, vous n'êtes par définition pas assez intelligent pour le déboguer." 
— Brian Kernighan

Le code qui suit les meilleures pratiques apprises de la documentation est déjà intelligent mon frère !! 

Écrivez un bon code propre et simple, facile à lire et à comprendre. Personne ne bénéficiera de ce code intelligent, y compris vous trois mois plus tard. Il est extrêmement difficile de travailler avec le soi-disant code intelligent par beaucoup de noobs (les développeurs indépendants peuvent le dire). Avez-vous déjà rencontré du code provenant d'un travail de modification d'EA ou du CodeBasequi était extrêmement compliqué pour des raisons que vous ne comprenez pas tout à fait ? Ne vous méprenez pas, je ne critique personne ni n'encourage un code simple pour une tâche complexe ; tout ce que je dis, c'est qu'il existe un moyen de s'assurer que même le code compliqué peut être facile à utiliser (je pense que c'est ce qu'est la créativité). Un code propre peut aider.

Voici quelques conseils pour écrire du code propre :

• Stylisez-le 
• Rendez-le cohérent
• Commentez-le
• Gardez-le au SEC (Keep it DRY - jeu de mot en anglais, DRY signifiant Don't Repeat Yourself (Ne Vous Répétez Pas), autrement dit, factorisez votre code) 

Stylisez-le :

J'utiliserai juste une fonction pour compter les positions par le type comme exemple

int CountPosByType(ENUM_POSITION_TYPE type){
 int counter = 0; 
  for (int i=PositionsTotal(); i>=0; i--)
     if (m_position.SelectByIndex(i))
     if (m_position.Magic()==MagicNumber && m_position.Symbol()==Symbol() && m_position.PositionType()==type)
      { counter++; }
  return counter;
}

La fonction est assez facile à comprendre mais elle ne suit pas les conseils de code propre ci-dessus, donc je vais d'abord la styliser. C'est simple : il vous suffit de cliquer sur le bouton bleu qui ressemble à un peigne à cheveux dans votre MetaEditor.

Voici à quoi ressemble notre code après l'avoir stylisé :

int CountPosByType(ENUM_POSITION_TYPE type)
  {
   int counter = 0;
   for(int i=PositionsTotal(); i>=0; i--)
      if(m_position.SelectByIndex(i))
         if(m_position.Magic()==MagicNumber && m_position.Symbol()==Symbol() && m_position.PositionType()==type)
            { 
                counter++; 
            }
   return counter;
  }

Vous voyez, juste en appliquant le style, notre code est passé de difficile à lire à lisible. Cela ne change même pas notre code, car nous devons faire le premier pas pour écrire du code propre et le rendre lisible car une fois que vous pouvez le lire, vous pouvez le modifier --Point.

Rendez-le cohérent :

Je ne peux pas vous dire à quel point j'ai fini par créer trop de variables pour à peu près le même travail à différents niveaux de fonction, alors pourquoi ne pas créer une variable globale ? Je vous encourage également à utiliser des noms de fonction cohérents, faciles à utiliser et faciles à retenir, qui expliquent clairement en quoi consiste la fonction, afin que vous puissiez vous en souvenir même dans 6 mois. Cela accélérera le délai de livraison de votre travail 3 fois par rapport à celui où il se trouvait puisque vous n'aurez pas à repartir de zéro pour créer une fonction qui se trouve déjà dans votre EA précédent, alors que vous pouvez simplement le copier à partir de vos travaux précédents.

Pour le nom de la fonction, faisons-le :

int CountPositionsByType(ENUM_POSITION_TYPE type)

Puisque nous sommes cohérents avec notre code, nous pouvons simplement rechercher et définir l'option de recherche dans les fichiers.      

À partir de là, vous pouvez rechercher votre fonction dans tous les EA et indicateurs, ce qui simplifie le travail. La prochaine fois que nous voulons créer la fonction, nous pouvons simplement la copier et la réutiliser dans d'autres EA.

La meilleure façon d'écrire du code cohérent est d'utiliser la POO (programmation orientée objet).

Le code cohérent est facile à utiliser, tandis que le débogage ne doit être effectué qu'à un seul endroit

Commentez-le :

Même les choses que les noobs appellent petites comme écrire des commentaires dans votre code peuvent faire une énorme différence sur votre productivité. Non seulement cela rendra le code lisible, mais aussi les commentaires peuvent être un rappel sur ce qu'est, par exemple, une variable.

Maintenant, définissons à nouveau le compteur cette fois avec un commentaire expliquant de quoi il s'agit :

int counter = 0; // Variable pour stocker le nombre de positions

La prochaine fois que nous voudrons accéder au compteur, ce sera comme ceci :

L'avantage de commenter du code dans MetaEditor est que le commentaire agira comme un rappel de ce qu'est une variable ou un morceau de code. Cette chose est très utile lorsqu'il y a trop de variables qui peuvent facilement être oubliées sur ce qu'elles sont.

Gardez-le DRY :

La POO peut aider beaucoup lorsqu'il s'agit de garder le code DRY (Don't Repeat Yourself). Faites également attention à ne pas avoir différentes fonctions qui peuvent faire à peu près le même travail. Par exemple, vous n'avez pas besoin d'avoir une fonction qui vérifie si une position existe par son type alors que vous avez déjà une fonction pour compter les positions par leur type.

05 : Abandonner l'écriture du code le plus court possible

"La lisibilité d'abord, puis tout le reste."

Maintenant, nous pouvons voir que les développeurs pensent qu'ils écrivent du bon code s'ils utilisent le moins de lignes possible ou le moins de caractères dans une ligne. Ce n'est pas sage non plus.

Le code écrit sera lu des dizaines, voire des centaines de fois, alors efforcez-vous d'écrire du code lisible quelle que soit sa longueur.

Je peux relier cela au fait que les développeurs sont parfois paresseux (j'ai été comme ça), nous avons l'impression d'implémenter peu de choses juste pour faire le travail sur Freelance ou quelque chose comme ça.

Envisagez de fournir des entrées faciles à utiliser sur votre EA. Écrivez le code pour gérer toutes les exceptions et alerter l'utilisateur de ce qui ne va pas, par exemple en alertant l'utilisateur si une entrée est définie sur zéro, auquel cas l'EA peut ne pas fonctionner correctement sans elle.

Voici ce que je vous dis,

   Les codes d'erreur, les codes de retour des trades, les erreurs de compilation et les exceptions dans le système sont pour vous, pas pour les utilisateurs. Alors, envisagez d'écrire du code pour fournir des alertes, des commentaires sur le graphique, etc. mais assurez-vous que l'utilisateur ne voit que ce qu'il est censé faire et quelles mesures doivent être prises pour arranger les choses.

Je sais que c'est ennuyeux de tout mettre en œuvre à partir de zéro, mais il y a toujours une meilleure façon de le savoir ! Vous pouvez les conserver quelque part dans les fichiers d'inclusion pour les inclure ou pour les copier-coller - vous pouvez trouver un moyen.

Conclusion

La bonne chose à propos des bonnes pratiques est qu'elles sont difficiles à suivre et à développer, mais une fois développées, elles vous suivront pour le reste de votre carrière.

 Merci de votre lecture !