De l’intérêt de Option Explicit
Tous vos modules Access (et d’ailleurs Excel, Word, Powerpoint, VB… partout où vous programmez en Visual Basic !) devraient démarrer par l’instruction
Option Explicit. Mais pourquoi donc ?
Principe
Option Explicit est une commande placée en début de module VBA. Elle vous oblige à déclarer toutes vos variables dans le code du module. Ça peut paraître un peu contraignant, mais il y a aussi des avantages :
- votre code sera plus structuré et plus « propre » ;
- vous pourrez détecter certaines erreurs plus facilement.
Ce qu’il ne faut pas faire
Voici un exemple de code tapé dans un module standard. Le module ne démarre pas par Option Explicit.
|
1 2 3 4 5 6 7 |
Sub Test() ma_variable1 = 12 ma_variable2 = 2 * ma_variable1 MsgBox "La première variable vaut : " & ma_variable1 MsgBox "La deuxième variable vaut : " & mavariable2 End Sub |
Vous avez vu l’erreur ? Et pourtant, si vous vérifiez votre code (menu Débogage / Compiler), ça passe correctement. Maintenant, si vous exécutez le code, le deuxième MsgBox affiche :
On s’attend à afficher la valeur 24. Oui… mais vous vous êtes trompé sur le nom de la 2ème variable. Du coup, le programme affiche le contenu d’une variable nommée mavariable2 qui n’a pas été renseignée, et qui est donc vide.
L’exemple est très simple ici, on voit l’erreur rapidement. Mais imaginez un programme de 3000 lignes, avec plusieurs variables qui posent problème : combien de temps allez-vous perdre pour les trouver toutes ?
Ce qu’il faut faire
Reprenez le programme ci-dessus, et ajoutez au-dessus la ligne :
|
1 |
Option Explicit |
Si vous compilez votre code (menu Débogage / Compiler, encore une fois), vous obtenez cette fois le message :
C’est normal, pour l’instant aucune variable n’est déclarée ! Donc vous allez rajouter des instructions Dim, en début de procédure, pour ajouter ces déclarations :
|
1 2 |
Dim ma_variable1 As Integer Dim ma_variable2 As Integer |
Et c’est maintenant que ça devient intéressant : si vous compilez encore le programme, vous obtenez malgré vos corrections :
C’est grâce à ceci que vous détectez la variable mal orthographiée.
Et pour ne pas l’oublier…
Et pour ne pas oublier de placer le Option Explicit en début de chaque module, vous pouvez tout simplement forcer Access à le faire pour vous :
- Démarrez Visual Basic Editor (VBE).
- Cliquez sur le menu Outils / Options.
- Sous l’onglet Éditeur, cochez l’option Déclaration des variables obligatoire.
Option Explicit manuellement, et de recompiler pour vérifier qu’il ne traîne pas de variable non déclarée !
DenisS > Je plussoie… 🙂
Personnellement, j’active systématiquement cette option. J’ai passé trop de temps à chercher pourquoi telle fonction ne retournait pas le bon résultat, alors que *tout* était parfaitement juste.
Sauf… que j’avais fait une inversoin de caractères dans le nom d’une variable… 😉
Alors que le compilateur, lui, ne risque pas de louper l’erreur, si on lui demande de vérifier ce point, bien entendu.
De plus, Variant est un type qui consomme inutilement de la mémoire, et qui est lent à traiter. Je ne l’utilise que quand je n’ai pas d’autre choix.
Jacky >
Tout à fait normal, le but de l’article est justement de montrer qu’on peut faire des erreurs très facilement dans le code, et ne pas les détecter facilement. Bien sûr, sur un programme de 10 lignes, ça saute aux yeux. Mais sur une application de 10000 lignes, ce genre de défaut va être bien plus compliqué à identifier.
De mon côté, je pense que c’est une erreur 😉 : si le langage est typé et permet la déclaration de variables, il faut le faire. Ça permet de structurer le code, de se poser les bonnes questions sur le type des données manipulées, et de faciliter la maintenance (entre autres).
Je comprends que, dans le monde Excel, ce n’est pas toujours une habitude, parce qu’Excel se veut tolérant sur l’écriture de macros. Il permet d’écrire des macros quand on est « Power User », sans avoir les contraintes de déclarations (l’option « Déclaration des variables obligatoire » est d’ailleurs décochée pour cette raison, dans Outils / Options). Du coup, toutes les variables sont implicites et de type Variant par défaut.
Mais ce n’est pas une bonne chose : je récupère ces temps-ci de nombreuses macros Excel (une application de 50000 lignes notamment) où :
Sur un grand nombre de lignes, c’est ingérable, alors qu’un typage fort élimine une grande partie des soucis.
La déclaration des variables force aussi indirectement la reconnaissance des autres instructions (puisque, si une instruction n’est pas connue, elle sera considérée comme variable, et signalée à la compilation). Par exemple, dans Excel, je vois beaucoup de gens se rater manuellement sur
ActiveCell. Si on tapeActivCell.ValueouActiceCell.Value, il y a une erreur au moment de l’exécution. AvecOption Explicit, l’erreur est signalée avant l’exécution, ou par un Débogage / Compiler. On gagne en efficacité sur le debugging (et on peut utiliser l’auto-complétion pour écrire les variables).Le débat est lancé 🙂 : quels seraient les bugs potentiellement causés par
Option Explicit?Bonjour Hervé,
si vous écrivez d’abord ma_variable2 et ensuite mavariable2, vous ne trouvez pas qu’il est normal que la MsgBox n’affiche pas le résultat???
Et si vous regarder le site de Jacques Boisgontier, bien souvent Option Explicit n’est pas mentionnée dans les macros, parfois elle peux même causé des bugs.
Merci !
A table.