J'écris ce petit tuto car il arrive que certaine personnes sur ce forum (et ailleurs) aient tendance à donner en réponse à des problèmes des solutions pas forcément très adaptées. (Non, je vise personne en particulier)
Introduction :
Une idée assez rependu sur le net au sujet de la programmation, c'est que l'on peut prendre la solution que l'on veut tant que ça marche.
Faux !
Arrivé à un certain stade, le dev ne cherche plus à avoir du code fonctionnel (sauf dans des cas particuliers). Il cherche à avoir la solution la plus correcte au niveau de sa conception. Et l'on reconnaît les bons dev car même dans leurs projets perso qui n'ont pas vocation à être distribués, la conception est bonne.
En fait, pour bien faire comprendre le problème, c'est comme de vouloir se rendre d'un point A à un point B en voiture. Il y a une quasi infinité de chemins possibles. Beaucoup de dev/conducteur s’offusquent quand on leur dit qu'un chemin est faux, répondant qu'ils arrivent à destination.
Mais imaginez que ce ne soit pas vous qui conduisez mais le chauffeur de taxi que vous venez d'appeler. Seriez vous toujours d'accord pour l'intégralité des chemin possible ? Certainement pas, si vous voulez aller de Brest à Paris, vous n'accepteriez pas qu'il passe par Pau (et ne vous en faites pas, c'est du taxi lowcost).
On se retrouve donc avec une poignée seulement de routes possibles acceptables, dont on sait qu'une est sûrement meilleur, mais qu'il est trop compliqué de calculer laquelle à cause de variables trop volatiles (météo, trafique, état de la route, etc.)
Et bien en programmation c'est pareil !
Il y a une infinité de solutions à un problème donné, mais seule quelque une sont acceptables. Et si il y à une solution vraiment meilleur, les conditions (proco, ram, system etc) font qu'elle sera presque impossible à trouver.
Quelques trucs à savoir :
Du coup, comment savoir quelles sont les « bonnes » solutions ? Et bien pour ça pas de miracle, faut suivre des cours de conception. Savoir utiliser UML pour matérialiser les problèmes, connaître les patterns utiles et avoir déjà eu affaire à beaucoup de cas.
Autant dire que c'est pas à la porté de tout le monde !
Mais heureusement, on peut quand même éviter de passer par Pau sans être un pro ^^
En suivant des règles simples comme en conduite (aller le plus tout droit possible, suivre les panneaux).
1- Ne pas avoir de code trop puissant.
Quand on à plusieurs choix, toujours prendre le code en fait le moins possible.
Exemple :
Je veux additionner deux valeurs, je vais donc utiliser la fonction _add(a, b) qui me retourne la somme, et pas Execute().
Cela ne veut pas dire qu'on ne doit pas utiliser de fonctions « trop » puissantes ! Si on veut connaître le résultat d'une expression tel que ((1 + 2) * 3 + 45) – 16, à moins d'avoir une fonction le faisant, Execute() est le bien venu !
2- Avoir du code cohérent.
Une fonction ne doit pas faire le thé et le café et se limiter à son rôle.
Exemple :
Ma fonction _NombreDeLettreDans($chaine, $lettre) qui me retourne, vous l'aurez comprit, le nombre de lettre dans une String, ne doit pas retourner dans @extend true/false pour savoir si la chaîne testée est un palindrome !
3- Limiter le couplage.
Chaque fonction, udf ou bout de code, doit avoir le minimum de dépendances avec d'autres.
Exemple :
Je veux créer une UDF de gestion de tableaux, puis une autre de gestion de chaînes, pour gérer mon tableau de chaînes.
La première UDF ne devra pas utiliser la seconde. Ça sera au programme principal de faire appel à l'une, puis à l'autre.
Bien sûr, tous ces conseil ne sont que des lignes directrices à suivre, et il arrive souvent que l'ont doive s'en écarter pour tout un tas de raisons. Mais sans raison valable, on se doit de les suivre le plus près possible.
Conclusion :
Au delà de l'aspect purement conceptuel, il ne faut pas oublier où nous nous trouvons : Un forum d'entraide pour AutoIt.
Beaucoup ici ne cherchent pas de défis et veulent juste apprendre petit à petit.
Aussi, au lieu de les noyer dans des solutions plus complexes les une que les autres, essayez de commencer par leur donner la solution la plus simple !
Il faut donc éviter à tout prit de sortir une regexp dès que l'ont parle de String (surtout quand sa signature contient « La solution la plus simple est toujours la meilleure » (et non je ne vise toujours personne!))
Car oui, on peut tout faire avec, mais mon 1- dis bien qu'on doit aller au plus simple et un membre sera sûrement plus heureux d'apprendre le fonctionnement de _StringBetween() que de trouver un StringRegExp($s_String, "(?s)" & $s_case & $s_Start & "(.*?)" & $s_End, 3) même si ce dernier se trouve dans ce premier.
C'est tout aussi valable pour la réflexion. On pourrait faire tout une script en n'utilisant que ça ! Et pourtant on ne le fait pas. C'est pas totalement sans raison !
Voilà, j’espère que ça pourra en aider certain dans leurs codes, et d'autres dans leurs aides !
ps : ya un piège à rebelle dans cet article, donc faites attention avant de poster
