Partager via

Éviter les conflits d’affectation de noms

  • Article

Un conflit d’affectation de noms se produit lorsque vous essayez de créer ou d’utiliser un identificateur défini précédemment. Dans certains cas, les conflits de nommage génèrent des erreurs telles que nom ambigu détecté ou Déclaration dupliquée dans l’étendue actuelle. Les conflits de nommage qui ne sont pas détectés peuvent entraîner des bogues dans votre code qui produisent des résultats erronés, en particulier si vous ne déclarez pas explicitement toutes les variables avant la première utilisation.

Vous pouvez éviter les conflits d’affectation de noms en ayant une bonne compréhension de la portée, du niveau module privé et du niveau module public.

Un conflit d’affectation de noms peut se produire lorsqu’un identificateur :

  • est visible à plusieurs niveaux de portée ;
  • a deux significations différentes au même niveau.

Par exemple, les procédures dans des modules différents peuvent avoir le même nom. Par conséquent, vous pouvez définir une procédure nommée MySub dans les modules nommée Mod1 et Mod2. Aucun conflit ne se produit si chaque procédure est appelée uniquement à partir d’autres procédures dans son propre module. Toutefois, une erreur peut se produire si MySub est appelé à partir d’un troisième module et qu’aucune qualification n’est fournie pour faire la distinction entre les deux MySub procédures.

La plupart des conflits d’affectation de noms peuvent être résolus en faisant précéder chaque identificateur d’un qualificateur composé du nom du module et, si nécessaire, du nom du projet. Par exemple :

YourProject.YourModule.YourSub MyProject.MyModule.MyVar

Le code précédent appelle la procédure YourSubSub et passe MyVar en tant qu’argument. Utilisez n’importe quelle combinaison de qualificateurs pour différencier les identificateurs identiques.

Visual Basic établit une correspondance entre chaque référence à un identificateur et la déclaration « la plus proche » d’un identificateur correspondant. Par exemple, si MyID est déclaré Public dans deux modules dans un projet (Mod1 et Mod2), vous pouvez spécifier le MyID déclaré dans Mod2 sans qualification à Mod2partir de , mais vous devez le qualifier comme Mod2.MyID pour le spécifier dans Mod1.

Cela est également vrai si Mod2 est dans un projet différent mais directement référencé. Toutefois, si Mod2 se trouve dans un projet référencé indirectement, c’est-à-dire un projet référencé par le projet que vous référencez directement, les références à la Mod2 variable nommée MyID doivent toujours être qualifiées avec le nom du projet. Si vous faites référence MyID à partir d’un troisième module directement référencé, la correspondance est établie avec la première déclaration rencontrée par la recherche :

  • Projets directement référencés, dans l’ordre dans lequel ils apparaissent dans la boîte de dialogue Références du menu Outils .
  • les modules de chaque projet. Notez qu’il n’y a aucun ordre inhérent aux modules dans le projet.

Vous ne pouvez pas réutiliser de noms d’objets d’application hôte, par exemple R1C1 dans Microsoft Excel, à différents niveaux de portée.

Conseil

Parmi les erreurs courantes dues à des conflits de noms, on peut citer les noms ambigus, les déclarations dupliquées, les identificateurs non déclarés et les procédures introuvables. En commençant chaque module par une instruction Option Explicit pour forcer les déclarations explicites des variables avant qu’elles ne soient utilisées, vous pouvez éviter certains conflits d’affectation de noms potentiels et les bogues liés à l’identificateur.

Voir aussi

Assistance et commentaires

Avez-vous des questions ou des commentaires sur Office VBA ou sur cette documentation ? Consultez la rubrique concernant l’assistance pour Office VBA et l’envoi de commentaires afin d’obtenir des instructions pour recevoir une assistance et envoyer vos commentaires.