Des arguments convaincants pour utiliser des plages locales dans Excel plutôt que des plages globales

Question

Je pense qu'il est peut-être préférable d'utiliser des noms de plages localisés dans Excel plutôt que des noms globaux. Dans Excel 2003, lorsqu'une plage est créée à l'aide de (ce que j'appellerai) la zone de saisie du nom en haut à gauche au-dessus de la colonne A, je sais qu'elle est globale. Je comprends qu'il est possible, bien que dans la plupart des cas improbable, d'avoir une plage localement sur une feuille avec le même nom, ce qui entraînerait un comportement très déroutant à la fois dans Excel et dans VBA ?

J'ai fait des recherches sur Google, mais je n'ai pas trouvé d'articles sur le sujet (je vais peut-être devoir en écrire un moi-même après cela). Je voulais savoir ce que d'autres développeurs Excel professionnels font et pourquoi ?

Answer 1

Les avis divergent quant à l'opportunité d'utiliser les noms locaux.
D'une part, il est souhaitable de restreindre la portée autant que possible, donc d'utiliser Local.
D'autre part, lorsque vous avez des noms locaux dupliqués (le même nom existe sur plusieurs feuilles), le risque d'erreur augmente rapidement, et si vous n'avez pas de noms locaux dupliqués, il n'y a pas beaucoup d'intérêt à les utiliser. De plus, il est alors facile de créer par inadvertance un nom global avec le même nom qu'un nom local, ce qui conduit à un comportement Excel/VBA confus et sujet à des erreurs (certains diraient bogues).
L'addin gratuit Name Manager (écrit par Jan-Karel Pieterse et moi-même) facilite la gestion des noms locaux en permettant des choses comme la conversion facile entre local et global, une meilleure visibilité des noms locaux, le filtrage et le signalement des noms globaux/locaux en double.
Du point de vue de VBA, je les utilise rarement, mais du point de vue des formules, il arrive que les noms locaux soient utiles.

Answer 2

Votre classeur est une application métier et les feuilles sont des modules. Pensez-y comme à tout problème de logiciel.

Vous voulez restreindre le plus possible la portée de vos noms :

1. Pour minimiser les abus accidentels et invisibles.
2. Pour éviter de se préoccuper de savoir si un nom a été utilisé précédemment.
3. Pour minimiser l'étendue de la recherche de "Qu'est-ce qui a changé ?"
4. Parce que cela ne vous coûte rien et que les globaux ne confèrent aucun avantage.

Les références croisées aux noms locaux représentent un travail supplémentaire et il est peu probable qu'il s'agisse d'un accident. Je ne suis donc pas d'accord avec Charles pour dire que la duplication des noms locaux augmente la probabilité d'erreurs.

Ce n'est pas pour rien que lorsque nous avons inventé la programmation structurée, nous nous sommes également débarrassés de Blank Common. Le raisonnement s'applique également aux feuilles de calcul.

Une chose qui peut aider à rendre vos modèles de tableur extra-robustes : Lorsque vous envisagez de déclarer un élément global ou que vous effectuez une référence entre feuilles, demandez-vous s'il est préférable de créer une fonction ou une classe. Ce n'est pas toujours le cas, mais j'ai constaté que c'est assez souvent le cas et que je peux réduire la complexité en encapsulant les calculs "intéressants".

Answer 3

Je pense que la question globale ou locale dépend du type d'utilisateurs auxquels vous avez affaire et du type de solutions que vous élaborez. Charles peut travailler avec des solutions où les utilisateurs sont fortement investis dans les plages et les formules ; je suis plongé jusqu'au cou dans le code VBA. Il y a un monde de différence dans les approches requises ici. Je ne dirais pas que Charles a tort - il a probablement raison pour les solutions qu'il développe. Mais il a tort pour moi .

Je travaille avec de nombreuses solutions modulaires qui génèrent par programme les mêmes plages sur différentes feuilles. J'utilise beaucoup les noms car cela permet de limiter l'utilisation de références de plages codées en dur dans le code et fournit également un moyen d'avoir des solutions génériques qui fonctionnent sur différents modèles. Je crée rarement des plages à l'aide de la barre de formule standard range-dropdown next - la création de noms locaux à cet endroit est une véritable plaie.

La remarque de Charles sur la confusion global/local ne s'applique pas à moi car tout est programmatique et une erreur de ce type serait un bug et non une frustration de l'utilisateur. Ils ne voient pas ces plages.

Dans les cas où les utilisateurs interagissent avec les noms, eh bien, j'aurais aimé qu'Excel signe les noms globaux d'une manière différente pour éviter la confusion des utilisateurs. D'après mon expérience, si j'ai défini les plages, les utilisateurs ne rencontrent pas de problèmes. Ils n'ont pas à s'inquiéter des problèmes locaux/globaux, car les noms sont déjà là.

N'entrons pas dans la question des noms de plages qui sont relatifs ou absolus... c'est une autre source de confusion pour l'utilisateur !

Answer 4

C'est une question d'opinion : des utilisateurs différents auront des préférences différentes.

J'utilise des noms globaux parce que je veux une étiquette pratique et stable qui identifie une plage dans tout le classeur - dans les formules de n'importe quelle feuille de calcul et dans les processus VBA de tout le projet.

Essentiellement, je considère une plage nommée comme une variable globale et un outil essentiel pour des processus stables entre les feuilles.

Les noms locaux servent à déclarer des plages différentes sur des feuilles différentes avec le même nom, et c'est une recette pour la confusion et les erreurs. Ceci étant dit, Joel Goodwin a fourni une réponse avec une très bonne raison d'utiliser les noms locaux : un code modulaire (comme un générateur de modèles) qui fait la même chose sur différentes feuilles. J'ai construit des générateurs de modèles qui font exactement cela.

J'utiliserais davantage les noms locaux si de meilleures interfaces étaient disponibles pour les visualiser et les utiliser dans VBA - le gestionnaire de noms de JKP est très utilisé dans mon travail, mais il n'élimine pas la confusion et les erreurs qui ont été intégrées par l'implémentation de Microsoft.