Re : A quoi font référence les variables dans une macro?
C'est une très bonne habitude à prendre que de déclarer ses variables et d'essayer (au moins !) de les typer.
Il est parfois NORMAL qu'une variable soit de type variant parce qu'elle est destinée à contenir soit du texte, soit des nombres ou encore que ce qu'elle contient change de nature au cours de la procédure.
Mais dans la majorité des cas une variable reçoit un type de donnée unique.
Ce n'est pas toujours facile de déterminer le type d'une variable, surtout quand on débute.
Quand dans le code on rencontre une erreur faisant référence au type de variable comme
"erreur d'exécution 13 incompatibilité de type"
C'est qu'une des variables est déclarée comme date par exemple et qu'on essaie d'y faire entrer un texte.
Dans ce cas, la solution que je trouve la plus pratique c'est de supprimer la déclaration du type de variable (donc laisser dim k mais supprimer le as ...) et de voir si le code passe. Si c'est le cas, revenir sur cette variable et essayer de comprendre et de trouver le bon type.
Quelques bonnes habitudes :
1) écrire Option Explicit en haut de module. Cela OBLIGE à déclarer toutes les variables (mais pas à les typer, juste à les déclarer.
2) déclarer toutes les variables en haut de procédure (ou de module quand elles sont communes à plusieurs macros). Cela aide grandement quand il faut débugger le type d'erreur indiqué plus haut
3) mettre toujours une majuscule ou plus dans un nom de variable (sauf les i, j k... qui servent juste de n° d'incrémentation dans les boucles) par exemple DateDepart au lieu de datedepart. De la sorte, quand tu écris dans le code datedepart, excel le transforme automatiquement en DateDepart et tu sais en un clin d'oeil que c'est OK alors que si tu écris datedépart, excel ne transforme pas et tu sais qu'il y a un pb.
4) Utiliser des noms de variables qui te parlent mais éviter les noms à rallonge quand même. Sinon on se retrouve avec des lignes de codes super longues, fractionnées sur plusieurs lignes, difficiles à comprendre et à modifier par la suite. A l'inverse, utiliser des noms trop courts oblige à mémoriser qu'on a mis par exemple la date de départ dans V34... pas très intuitif. Donc c'est comme en tout, il faut un juste équilibre.
5) Typer tant que l'on peut donc les variables
6) Ne pas hésiter à mettre un commentaire à côté de la déclaration de variable quand il peut y avoir une ambiguité (genre c'est la date de départ du colis et pas celle de la facture)
7) Commenter son code, surtout au début et encore plus si ce code est appelé à être repris plus tard ou par d'autres
Je suis d'accord avec toi que ce n'est pas très intuitif tout ça mais encore une fois tu es parti pour apprendre sur un exemple qui m'a l'air d'être vraiment complexe pour quelqu'un qui découvre le VBA. Pourquoi ce choix ?
J'ai encore en souvenir ma première usine à gaz, qui est le premier classeur avec des formulaires que j'avais essayé de créer. Un truc invraisemblable ou j'avais voulu gérer des trucs bien trop compliqués. Je n'étais jamais allée au bout et j'avais fini par tout refaire en repartant de 0 quelques années plus tard car la logique même de ma construction n'était pas adaptée. Depuis j'ai compris la leçon : travailler par modules. Faire un petit truc qui fonctionne parfaitement. Ajouter ensuite une fonctionnalité, la tester et ensuite ajouter encore autre chose. La technique de la mayonnaise : si tu mets toute l'huile d'un coup elle foire.
Mon conseil : lance toi sur un développement que tu fais toi. Un truc simple. C'est la meilleure façon de comprendre la logique derrière tout ça.
Il n'y a pas une seule façon d'écrire un code, bien loin de là. On reconnait sans problème la patte de certains programmeurs connus, comme on reconnait l'écriture d'un romancier. Mais on n'apprend pas à écrire une langue en commençant par des vers de poésie