Ceci est une page optimisée pour les mobiles. Cliquez sur ce texte pour afficher la vraie page.

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
 
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

Les cookies sont requis pour utiliser ce site. Vous devez les accepter pour continuer à utiliser le site. En savoir plus…