Astuces, conseils et précautions typographiques

Certaines règles dans l’écriture du code et la façon de nommer les variables aident à repérer certaines erreurs comme les fautes de frappe ou les mots non reconnus par l’éditeur.

Astuces

Tous les mots-clefs de VBA ainsi que les noms de propriétés, d'événements et de méthodes sont construits selon le même principe : chaque composante du mot commence par une majuscule, qu’il s'agisse d’un mot simple (Name, Workbook, Cell, …) ou composé (ActiveWorkbook, ScreenUpdating, BeforeClose, …).

Quelle que soit la combinaison de minuscule(s) et majuscule(s) utilisée pour l’écriture du code, la typographie normale (majuscule en début de mot) est rétablie lors de la validation de la ligne.

Ainsi, que l’on entre WORKBOOK, workbook ou WoRkBoOk, le résultat final sera toujours Workbook. Par contre, en cas de faute de frappe, workbok par exemple (un "o" manquant), le mot n’est pas transformé.

C’est également le cas si un mot n’est pas reconnu. Cela se produit typiquement lorsqu’on travaille avec plusieurs versions d’Excel : si l’on tente d’utiliser sous Excel 97/98 une propriété apparue avec Excel 2000/2001, l’éditeur ne peut la reconnaître.

La transformation est donc une information. Son absence indique une faute de frappe, ou que le mot n’existe pas.

Par conséquent, lors de la frappe du code, il ne faut SURTOUT PAS essayer de respecter la structure des mots VBA : workbok et Workbok contiennent la même faute de frappe ("o" manquant), mais l’erreur est plus facile à repérer dans le premier cas, grâce à l’absence de majuscule.

Par conséquent, il est vivement conseillé de toujours taper le code en minuscules, car cela aide à repérer les fautes de frappe et les mots non reconnus.

À condition que celles-ci aient été préalablement déclarées, le même principe s’applique également pour les noms de variables :

Si une variable NbLignes a été déclarée, la saisie de nblignes ou de NBligNes aboutit à la graphie NbLignes.

C’est pourquoi il est recommandé de construire les noms de variables en utilisant également une majuscule au début des mots, afin de bénéficier des mêmes avantages.

Le fait que ce mécanisme ne fonctionne que pour les variables ayant été déclarées, est une raison supplémentaire pour choisir Option Explicit dans les préférences de VBA.

Conseils

Nous venons de voir que l’emploi d’au moins une majuscule dans les noms de variables permettait par une simple vérification visuelle de repérer les fautes de frappe.

Par ailleurs, la façon de nommer les variables a d’autres conséquences. Certains développeurs, peut-être pour rendre leur code plus concis, usent (selon moi abusent) de noms abrégés.

Fig. 1 - Exemple de menu, avec 6 articles.

Par exemple, pour définir un menu ayant 6 articles (figure 1), ils utiliseront les déclarations suivantes :

Dim M1 As Object, A1 As Object, A2 As Object, A3 As Object, A4 As Object, A5 As Object, A6 As Object

M1 désignant le premier menu créé, A1 le premier article de menu, …

Cette approche économise la frappe de quelques caractères, mais demande un effort de mémorisation non justifié selon moi. Il est facile de se rappeler que A3 correspond au 3ème article de menu, beaucoup moins qu’il s’agit des corrections à apporter à la proposition de planning faite par l’application.

Pour ma part, je préconise de choisir des noms de variables suffisamment évocateurs. Voici ceux que j’ai utilisés pour ce menu :

Dim MPlanning As Object, Propal As Object, Contraintes As Object 
Dim Corrections As Object, VerifCH As Object, Validation As Object, CopiePlanning As Object

Enfin, pour éviter toute ambiguïté, il ne faut JAMAIS donner à une procédure ou à une variable, un nom correspondant à un mot-clef, une propriété, une méthode ou un événement.

Précautions

Le français étant une langue accentuée, j’avais pris l'habitude dans Excel d’utiliser des noms comme Arrêt, Arrivée, Départ, Données, … aussi bien dans les feuilles de calcul que dans les macros XL4.

Quand j’ai commencé à utiliser sérieusement VBA en 1997, j’ai constaté des comportements bizarres, en particulier des appels de procédures qui semblaient ne pas fonctionner. Je me suis alors rendu compte que cela se produisait quand le nom de la procédure comportait un accent.

Depuis lors, j’évite systématiquement les caractères accentués dans les noms de procédures et dans celui des variables.