Question général sur les macros

Carnage029

XLDnaute Occasionnel
Bonjour à tous :)

Je sais pas trop si c'est ici la place pour un tel fil mais je me lance quand même :)

Je voulais avoir des éclaircissement quant à la "propreté" du code.

- Quand doit on créer un module spécial ? Pourquoi ne pas écrire le code dans les emplacements de feuille ou de workbook ?

- Au niveau des déclarations, est t'il toujours préférable de dimensionner ses variables (string, integer etc) ou s'en passer est une façon "correcte" de coder

- Comment créer proprement ses fonctions/procédure, utilisation des private, public et tout autre argument que je ne connais pas.



Ce post est à vocation "éducative" et non pas de répondre à un problème particulier, si jamais vous voulez rajouter des questions faites vous plaisir :)


(Si ce post n'a pas sa place ici merci de me le signaler)
 

Orodreth

XLDnaute Impliqué
Re : Question général sur les macros

Bonjour,

- Quand doit on créer un module spécial ? Pourquoi ne pas écrire le code dans les emplacements de feuille ou de workbook ?
Personnellement, j'ai tendance à bannir les codes des feuilles pour la raison que si tu désires copier une feuille, si du code est présent, ça copie également le code, ce qui n'est pas forcément souhaitable.
Donc je préfère utiliser des modules. C'est également plus propre si tu désires exporter le code directement, puisque tu peux exporter un module, pas une feuille.

En revanche, concernant le workbook, je m'en sers allégrement. Soit parce que le code ne peut se mettre qu'ici (ouverture de classeur, manipulation de feuilles, fermeture de classeurs, before_DoubleClick/RightClick, etc etc ...), soit parce qu'il s'agit d'un code temporaire qui n'a pas vocation à être pérenne.

- Au niveau des déclarations, est t'il toujours préférable de dimensionner ses variables (string, integer etc) ou s'en passer est une façon "correcte" de coder ?
Pas sûr de comprendre ce que tu veux dire par "dimensionner" les variables. Pour autant que je sache, seuls les tableaux ont véritablement besoin d'une structure dimensionnée.

- Comment créer proprement ses fonctions/procédure, utilisation des private, public et tout autre argument que je ne connais pas ?
Concrètement, le plus cohérent est encore de regrouper tes fonctions/procédures par module, en fonction de la logique des procédures et fonctions.
Par exemple, toutes les procédures et fonctions devant intervenir sur une feuille précise sont à mettre dans un module spécifique.
Autre exemple, tout ce qui est Traçabilité/conversion devrait être mis dans un module dédié: Tools.

Concernant la visibilité des variables/procédures/fonctions, là encore, c'est la cohérence qui prime: il faut réfléchir en terme d'accès à l'information ou à l'action.
Par exemple, tu peux piloter toute ton application Excel depuis le module ThisWorkbook, qui utilise des Launchers répartis dans les différents modules applicatifs.
Ces launchers seraient publiques, puisqu'il faut y avoir accès depuis l'extérieur du module, le reste des traitements pourraient alors être Private parce que réservés à l'usage interne du module.

Un point que tu n'as pas cité est le nommage des différents éléments (variables/procédures/fonctions).
De manière générale, tous les noms doivent être explicites en soi dans le code, ils servent à comprendre la logique métier.
Concernant les variables, certaines conventions de nommage impliquent de citer le type de la variable dans le nom.
Exemple d'une variable String pour un champ "Prénom": str_Prenom, ou d'une variable integer pour un champ "Âge": i_Age.

Si tu désires faire une distinction entre nommage métier et nommage technique, tu peux changer de langue. Ainsi le français est utilisé pour le métier, l'anglais pour le technique.
C'est un peu plus contraignant, mais d'un point de vue informatique, c'est logique, la langue "informaticienne" étant l'anglais. Rien d'obligatoire sur ce point en revanche.

Dernier point: les commentaires. Ils sont importants pour comprendre les logiques internes du code (et crois moi, c'est pas de la tarte des fois).

Si tu as des questions, n'hésite pas.

Cordialement,
 

Carnage029

XLDnaute Occasionnel
Re : Question général sur les macros

Merci de ce retour, j'ai personnellement tendance à n'utiliser que des modules, (parfois beaucoup) avec comme contrainte qu'il y ait le moins de liaisons entres les différents modules.

Je crée un "main" qui m'appelle tout mes modules quand je le souhaite.

Après j'avoue que je ne dimensionne jamais mes variables (genre le dim i as integer je le met jamais)


EDIT : Gilbert je vois que ton lien mène vers une page ou on ne peut pas télécharger le pdf... Il n'ya que l'aide mémoire de disponible à moins que ce soit cela
 
Dernière édition:

Orodreth

XLDnaute Impliqué
Re : Question général sur les macros

Re,

L'instruction Dim sert pour déclarer une variable. Dans les options de VBA, définir que le projet doit être Option Explicit, c'est se simplifier la vie, beaucoup plus lisible en soi, et plus propre au niveau déboggueur/compilateur.
 

Orodreth

XLDnaute Impliqué
Re : Question général sur les macros

Ca force la déclaration des variables, de sorte que l'application plante dès que tu essayes de compiler, signalant l'erreur.

Ca évite par exemple de travailler avec une variable str_Pattern_RegEx tout au long d'une fonction, et de renvoyer str_Patern_RegEx comme résultat par simple faute de frappe.
 

Staple1600

XLDnaute Barbatruc
Re : Question général sur les macros

Bonjour à tousààààààààEDITION: Salut à toi Chhris ;)


Carnage029
Ne pas oublier la sempiternelle touche F1 (ici quand on est dans l'éditeur VBE)
Faire alors une recherche sur le mot-clé: variables
Tu trouveras aussi beaucoup d'autres explications et exemples sur le VBA dans l'aide (qui est à mon sens la première source pour débuter en VBA)
Extrait de l'aide VBA
Déclaration de variables


Lors de la déclaration de variables, vous employez généralement une instruction Dim. Une instruction de déclaration peut être placée dans une procédure pour créer une variable de niveau procédure. Elle peut être également placée au début d'un module, dans la section Déclarations, pour créer une variable de niveau module.
L'exemple suivant crée la variable strName et spécifie le type de données String.

Dim strName As String Si cette instruction apparaît dans une procédure, la variable strName peut être utilisée uniquement dans cette procédure. Si l'instruction apparaît dans la section Déclarations du module, la variable strName est accessible dans toutes les procédures du module, mais pas dans les procédures des autres modules du projet. Pour faire en sorte que cette variable soit accessible dans toutes les procédures du projet, faites-la précéder de l'instruction Public, comme dans l'exemple suivant :

Public strName As String Pour plus d'informations sur l'affectation de nom à vos variables, recherchez "Règles d'affectation de noms Visual Basic" dans l'aide de Visual Basic.
Les variables peuvent être déclarées dans les types de données suivants : Boolean, Byte, Integer, Long, Currency, Single, Double, Date, String (pour les chaînes à longueur variable), String * length (pour les chaînes à longueur fixe), Object ou Variant. Si vous ne spécifiez pas le type de données, Variant est pris par défaut. Vous pouvez également créer un type défini par l'utilisateur à l'aide de l'instruction Type. Pour plus d'informations sur les types de données, recherchez "Type de données" dans l'aide de Visual Basic.
Vous pouvez déclarer plusieurs variables dans une instruction. Pour spécifier un type de données, vous devez inclure le type de données pour chaque variable. Dans l'instruction suivante, les variables intX, intY et intZ sont déclarées avec le type Integer.

Dim intX As Integer, intY As Integer, intZ As Integer Dans l'instruction suivante, intX et intY sont déclarés avec le type Variant ; seul intZ est déclaré avec le type Integer.

Dim intX, intY, intZ As Integer Vous pouvez omettre le type de données de la variable dans l'instruction de déclaration. Dans ce cas, la variable prend le type Variant.
Utilisation de l'instruction Public

L'instruction Public permet de déclarer des variables publiques dans un module.

Public strName As String Les variables publiques peuvent être utilisées dans n'importe quelle procédure du projet. Si une variable publique est déclarée dans un module standard ou dans un module de classe, elle peut également être employée dans n'importe quel projet faisant référence au projet où la variable publique est déclarée.
Utilisation de l'instruction Private

L'instruction Private permet de déclarer des variables privées dans un module.

Private MyName As String Les variables privées peuvent être utilisées uniquement par les procédures du même module.
Note Lorsqu'elle est utilisée au niveau module, l'instruction Dim équivaut à l'instruction Private. Il convient parfois d'utiliser l'instruction Private pour simplifier la lecture et l'interprétation de votre code.
Utilisation de l'instruction Static

Lorsque vous employez l'instruction Static à la place de l'instruction Dim, la variable déclarée conserve sa valeur entre les appels.
Utilisation de l'instruction Option Explicit

Vous pouvez déclarer implicitement une variable dans Visual Basic avec une simple instruction d'affectation. Toutes les variables ainsi déclarées sont de type Variant. Les variables de type Variant nécessitent plus de ressources mémoire que les autres. Vous améliorerez l'efficacité de votre application en déclarant les variables explicitement, avec un type de données spécifique. La déclaration explicite de toutes les variables réduit les risques de conflit d'affectation de nom et de faute de frappe.
Si vous ne souhaitez pas que Visual Basic effectue des déclarations implicites, placez l'instruction Option Explicit dans un module avant toute procédure. Cette instruction impose la déclaration explicite de toutes les variables dans le module. Si un module inclut l'instruction Option Explicit, une erreur se produit au moment de la compilation si Visual Basic rencontre un nom de variable n'ayant pas été précédemment déclaré, ou lorsqu'une faute de frappe se glisse dans un nom de variable déclarée.
Vous pouvez définir une option dans votre environnement de programmation Visual Basic prévoyant l'inclusion automatique de l'instruction Option Explicit dans tous les nouveaux modules. Pour la modification des options d'environnement de Visual Basic, consultez la documentation de votre application. Notez que cette option ne change pas le code existant déjà écrit.
Note Vous devez déclarer explicitement des tableaux fixes et des tableaux dynamiques.
 
Dernière édition:

chris

XLDnaute Barbatruc
Re : Question général sur les macros

Bonjour

Pour compléter les réponses d'Orodeth et Stapple que je salue, juste une petite précision (my 2 cents :) même si c'est dit dans l'aide en ligne) :

Dim déclare la variable et la dimensionne d'une certaine manière car cela réserve en mémoire, selon le type de la variable, 1 ou plusieurs octets (jusqu'à 22 octets + nombre de caractères pour le variant contenant des caractères).

Si on ne déclare pas, chaque variable est considérée comme variant et occupe au minimum 16 octets.

Déclarer optimise donc l'espace mémoire.

L'option explicite évite les fautes de frappe ou l'utilisation d'un même nom de variable par erreur : j'ai vu nombre de bug liés à une faute de frappe dans le nom d'une variable...

Pour ma part j'utilise souvent le module de feuille dans les cas des événement feuilles en particulier dans un classeur protégé où l'utilisateur n'a pas possibilité de dupliquer.
Si le même code doit se trouver sur plusieurs feuilles cela m'évite de gérer les noms de feuilles concernées dans le module Workbook et me parait plus souple mais chacun adopte la méthode qui lui parait la plus adapté à chaque projet.

L'important est de bien découper le code, de se créer des procédures et fonctions réutilisables à divers endroits du code, voire dans d'autres projets, par simple passage de paramètres depuis la procédure appelante.

Et commenter, commenter, commenter que ce soit vous ou d'autres qui maintiennent le code, c'est indispensable.
 
Dernière édition:

Misange

XLDnaute Barbatruc
Re : Question général sur les macros

Bonjour à tous

My 2 cents also,

Certes il n'est pas obligatoire de dimensionner les variables (sauf les tableaux internes ou arrays) mais c'est une EXCELLENTE habitude à prendre.
Je ne le fais pas quand j'écris un code de quelques lignes pour faire un test. Mais quand j'écris des macros dans un classeur destiné à servir de façon répétée, appelé à s'enrichir de nouvelles fonctionnalités, je commence par mettre option exlicit en début de module. Ceci oblige à déclarer les variables.

Sur cette rubrique
Ce lien n'existe plus
il y a plusieurs pages consacrées aux variables et à l'intérêt de les déclarer. PAs la peine de les recopier ici et de redire ce que mes camarades ont écrit plus haut. MAis je dirai aussi qu'un avantage de la déclaration c'est que cela oblige à se poser la question : qu'est ce que c'est ? qu'est ce que cette variable va contenir (texte, nombres, dates, tantôt l'un tantôt l'autre...), quelle sera la taille maxi de cette variable ?
Quand on ne déclare pas les variables excel essaie de se débrouiller pour que ça passe. MAis ça ne passe pas toujours. Voir un exemple ici
Ce lien n'existe plus
Et surtout surtout ça m'évite d'avoir un code qui ne fonctionne pas juste parceque je n'ai pas vu que j'avais appelé une fois une variable Truc et la fois suivante tRuc...
En plus quand la variable est déclarée, disons tRuc, l'intellisense fait qu'en tapant truc, excel transforme en tRuc. Le fait de voir cette transformation me permet de vérifier en un clin d'oeil qu'excel et moi nous parlons bien de la même variable :)
C'est pour cette raison qu'il est très vivement conseillé de mettre une ou plusieurs majuscules dans un nom de variable (plus la lisibilité).

Concernant l'organisation des macros dans les modules.
J'essaie pour ma part de regrouper dans un même module les macros qui fonctionnent "ensemble" pour faire un ensemble de traitement de données importées par exemple, ou des calculs sur des données déjà présentes.
Mettre une macro par module n'a aucun sens et cela alourdit le classeur.
A l'inverse mettre des milliers de lignes de macros dans un seul module devient vite ingérable.
Mais à part ces extrêmes, il n'y a pas de règle absolue.

Pour ma part j'évite toujours de dupliquer une macro sur plusieurs feuilles. Quand je veux la modifier je n'ai de cette façon qu'un seul endroit ou agir.
 

Discussions similaires

Statistiques des forums

Discussions
311 709
Messages
2 081 779
Membres
101 816
dernier inscrit
Jfrcs