Question bonnes pratiques du codage...?

Bonjour à tous,

On peut renommer les objets en VBA...

Certains sites le conseille et même le recommande, d'autres pas...

Quelqu'un peut-il me dire les avantages ou les inconvénients à le faire ?

Car j'avoue que j'ai bien du mal à me faire une idée...

auriez vous la gentillesse de m'éclairer à ce sujet ?

Merci aux âmes de bonne volonté...

Bonjour,

Les objets en général c'est un peu vague ! On manipule principalement 2 sortes d'objet avec VBA : les objets Excel, auxquels tu donnes naturellement des noms, sans même y penser spécialement, noms de classeurs, noms de feuille, etc. et il n'y a pas de raisons de ne pas leur en donner de façon à s'y retrouver plus facilement parmi eux. Moins évident en ce qui concerne les formes, parce que beaucoup d'utilisateurs ne savent pas où ils peuvent modifier le nom générique mis par Excel (c'est tout simplement dans la zone Nom, et il convient de valider le nouveau nom par la touche Entrée pour qu'il soit pris en compte). Bien usité en ce qui concerne les noms de plage dont l'utilité n'est plus à démontrer (je conseillerais toutefois de ne pas les multiplier à l'infini, car on ne fait alors qu'en compliquer la gestion, un nom judicieusement placé permet d'atteindre n'importe quelle plage ou cellule d'une feuille et l'on peut souvent s'en contenter...)

Et en second lieu, les contrôles de Userforms, auxquels il me semble que vont tes pensées ! D'abord ce sont des objets comme les autres, qu'on utilise, et je ne vois aucune raison de ne pas leur donner de nom reflétant leur utilisation particulière, qui permettra à l'utilisateur de s'y retrouver spontanément, sans avoir à réfléchir à qui est qui ? à chaque fois... Autant que je sache, c'est généralement conseillé et j'avoue ignorer les arguments de ceux qui éventuellement le déconseilleraient.

Il est d'usage fréquent d'utiliser un préfixe indiquant la nature du contrôle, c'est certainement utile, mais il est aussi utile de pouvoir utiliser ces contrôles en boucles, d'où un renommage permettant cette utilisation... Quand il peut y avoir contradiction entre ces deux types d'exigences, je n'hésite pas à déroger à la première pour confondre par exemple des ComboBox et des TextBox avec un même nom générique pour les utiliser dans une même boucle...

Ceci étant on dispose aussi d'autres choix alternatifs (utilisation de TypeOf, de la propriété Tag, etc.) et donc les choix finaux résulteront de la conception d'ensemble qu'on privilégiera, de compromis divers, de préférences... A chacun de voir la situation qui lui convient le mieux à un moment donné.

Je dirais donc en la matière :

1) OUI, c'est conseillé de renommer,

2) Il est bon de prendre en considération certaines règles de renommage communément admises,

3) Et de ne pas hésiter à s'en affranchir si on le trouve plus judicieux !

Cordialement.

Bonjour,

c'est très bien, MFerrand, ta longue description est vraiment parfaite ! la seule chose que je peux ajouter, c'est que pour renommer un objet, c'est pas obligatoire d'en faire la déclaration à l'État Civil.

dhany

c'est pas obligatoire d'en faire la déclaration à l'État Civil.

Euh ! Non ! Tu peux le faire en catimini, ou sous le manteau...

Bonjour MFerrand et dhany,

Merci MFerrand pour cette explication magistrale qui décortique bien le sujet...

En posant ma question, je pensais effectivement au renommage des UserForms et des différents contrôles qu'ils peuvent contenir; tu as visés juste.

Cela conforte ce que je pensais et je vais donc continuer à utiliser des noms personnalisés et préfixés conformes aux conventions typographiques , car je trouve ça très pratique.

Merci encore et toujours pour la justesse des tes propos...

bonjour à tous

nommer, ce n'est pas propre à VBA ni à tout autre langage.

sur Excel, on conseille* AUSSI de nommer les cellules qui ont une signification particulière et qu'on utilise dans plusieurs endroits, les Tableaux, les TCD, les feuilles, et toutes autres sortes d'entitées.

c'est donc bien une règle universelle

valable dans toute l'informatique, comme pour les gens et les voitures

* moi, si on fait des fichiers durables, j'exige de nommer au maximum

car dans 6 mois...

Bonjour à tous

Au passage pour apporter un peu de code dans cette discussion,

tu peux totalement t'affranchir du nom pour gérer le type du contrôle, tu peux utiliser la fonction typename() qui prend un contrôle en argument.

Je recommande tout de même de renommer les contrôles en gardant ComboBox devant par exemple, c'est vrai que c'est plus pratique ensuite quand tu codes pour pouvoir savoir qu'est ce que tu manipules.

bonne remarque !

TCD_Banque signifie le TCD avec les bilans par banques

TAB_Frais le Tableau des frais

il doit y avoir des tutos de recommandations sur le net...

Ou encore TextBox_jour pour stocker le jour, TextBox_mois, TextBox_annee, enfin ça c'est si on veut une textbox pour chacun des champs bien sûr, on peut aussi faire une simple TexBox_date aussi, en tout cas c'est toujours plus pratique de savoir si ta TextBox que tu vas peut-être vouloir tester par la suite contient bien un mois entre 1 et 12, moins facile à comprendre avec TextBox1, TextBox2, TextBox3 ...

Bien nommer ses variables et ses objets c'est toujours important pour rendre son code lisible.

Dans les autres bonnes pratiques de la programmation il y a aussi le fait de mettre des tabulations à chaque entrée dans un With, For, If, Do... Ainsi que les commentaires qui sont très importants, il est possible parfois de revenir sur un programme après 2 semaines et ce n'est pas toujours évident de s'y retrouver sans commentaires, et c'est également mieux si quelqu'un passe derrière toi et cherche à comprendre la logique de ton code

Je recommande tout de même de renommer les contrôles en gardant ComboBox devant par exemple, c'est vrai que c'est plus pratique ensuite quand tu codes pour pouvoir savoir qu'est ce que tu manipules.

... Quand on comence a être atteint d’Alzheimer peut-être... si on ne peut pas se souvenir que tb sont les Textbox, cbo les Combos et cmd pour les buttons.

Pour ma part comme je déteste le noms à rallonge qui ne permettent pas de voir la totalité d'une ligne dans un écran, je m’abstiens de participer quand c'est codé comme ça !

A+

c'est sans doute ce que voulait dire Ausecours

mais il n'est pas rentré dans ce "détail"

si on met CMD pour bouton, c'est bien, mais il faut un tuto commun à tous.

au fait, en cmd ou CMD

Je recommande tout de même de renommer les contrôles en gardant ComboBox devant par exemple, c'est vrai que c'est plus pratique ensuite quand tu codes pour pouvoir savoir qu'est ce que tu manipules.

... Quand on comence a être atteint d’Alzheimer peut-être... si on ne peut pas se souvenir que tb sont les Textbox, cbo les Combos et cmd pour les buttons.

Pour ma part comme je déteste le noms à rallonge qui ne permettent pas de voir la totalité d'une ligne dans un écran, je m’abstiens de participer quand c'est codé comme ça !

A+

Personnellement je prends ce que me donne Excel pour les noms, je me contente juste de rajouter un peu de texte pour rendre le nom du contrôle plus clair, si ça ne tient pas en largeur sur l'écran je fais un coup de "_" dans la ligne à un moment jugé utile

Je préfère également déclarer mes variables de façon lisible en mettant as string, as double, etc plutôt que les % et autres caractères.

Bonjour,

Si je puis faire un petit complément personnalisé, qui porterait plutôt sur ce en quoi j'aurais tendance à déroger au type de convention que tu cites (et qu'il est en tout état de cause bon de connaître). Si d'ailleurs on regarde un lot de procédures d'origines diverses, respectant plus ou moins ces conventions, il sera rare que l'on ne trouve pas des éléments plus personnalisés qui signent en quelque sorte un style d'écriture de code... Lorsque je lis certaines macros citées par tel ou tel demandeur, dans beaucoup de cas (et c'est croissant dans la mesure où l'on se cotoie...) je n'ai pas besoin de chercher à savoir qui l'a écrite au départ, le style parle, et éventuellement si elle a été modifiée par la suite (rupture de style)...

Pour ce qui est de la lecture, le facteur déterminant de lisibilité demeure l'indentation, assortie de l'organisation des procédures dans les modules.

Par indentation j'entends très précisément : déclaration de procédure à la marge et retrait systématique d'une tabulation du code de la procédure, seules restent à la marge les étiquettes de branchement (que VBA ramène d'ailleurs automatiquement à cet emplacement) et que l'on distinguera donc au premier coup d'oeil s'il y en a. J'admets la variante consistant à laisser à la marge les déclarations de variables (bien qu'elle me gêne parfois un peu) dès lors qu'elle interviennent comme prévu toutes en début de procédure, avant tout code exécutable. On obtient donc un alignement de base en retrait d'une tabulation, à partir duquel d'autres retrait mettront en évidence le code placé à l'intérieur d'instructions composées (type With... End With, For... Next, If... [ElseIf]... [Else]... End If, Select Case... End Select, etc.).

Pas de ligne sautée interrompant le mouvement de l'oeil. Pas de commentaires, ralentissant la lecture, sauf à titre de balises découpant des parties distinctes de code.

Par contre une ligne sautée entre procédures dans le module est indispensable pour qu'on puisse les distinguer.

Là l'ordre conventionnel est : Déclarations, Procédures Function, Procédures Sub. Pour les déclarations, il y a intérêt à le respecter car certaines ne fonctionneront pas si non situées en tête de module. Si Procédures Property, je les place à la suite des déclarations dans l'ordre Property Get, Property Let, Property Set.

Pour les modules spécifiques de documents (feuilles, classeurs, userforms), je considère qu'il est le plus sage de laisser VBA placer les procédures d'évènements, c'est ainsi qu'on les retrouvera le plus vite. Et si l'on ajoute d'autres procédures, les placer en tête de Module à la suite des déclarations, zone répertoriée sous le nom de (General) dans ces modules.

Si en 25 ans je n'ai pas trop varié dans la façon d'écrire et organiser le code, parce que les premiers modèles qui m'ont inspiré respectaient globalement ces règles, la pratique et l'expérience lors de la reprise de code écrit antérieurement m'ont conduit à des ajustements pour tenter d'obtenir la situation me permettant de travailler le plus efficacement...

Je n'oserais prétendre que la situation qui me paraît la meilleure en ce qui me concerne doit valoir pour tout le monde ! Cependant, dans la mesure où elle s'est bâtie sur des règles conventionnelles que je n'ai pas inventées et qui demeurent au coeur de mes modalités de travail depuis mes débuts, il me semble que cela tend à valider l'intérêt de respecter quelques règles de base, et les essayer devrait permettre de se rendre compte si elles permettent de mieux travailler sur du code, plus efficacement et plus vite...

Pour ce qui est des variables, je prendrais un peu plus de distance avec les conventions citées, pour deux raisons. La première est qu'une fois nommée une variable, on va souvent l'utiliser pas mal de fois dans le code, donc l'écrire, et plus un nom est long plus cela prendra de temps à l'écrire maintes fois. Je suis donc partisan de noms courts (comme de façon générale de toute méthode permettant de moins écrire sans toutefois nuire à la compréhension immédiate).

La seconde est qu'il y a un lien avec le contexte d'utilisation, et la compréhension relative aux noms donnés n'est pas indépendante d'une variable à l'autre mais forme un système dans lequel la compréhension résulte tout autant de l'interdépendance des noms donnés.

Et dans la mesure où au-delà de 3 caractères, je commence à trouver qu'un nom de variable est long, je n'applique pas de préfixage des variables (2 ou 3 caractères en plus !) (ce qui ne vaut toutefois pas pour les modules de Classe, où l'on est hors contexte utilisateur, et où l'identification de la classe plaide en faveur du respect de règles plus rigoureuses), mais respecte certaines règles personnelles assez souples mais qui dans un contexte donné d'utilisation ne me semblent pas nuire à une compréhension immédiate.

Exemples : mes variables numériques Integer ou Long (NB- je n'utilise jamais Byte car ne pouvait être déclaré dans la première version de VBA (VBA4) pour Excel, et comme les tests faits ont montré qu'elle était particulièrement peu rapide, cela n'incite pas à l'utiliser...) sont le plus souvent à un caractère (lettre toujours minuscule), parfois à 2 (2e lettre en Majuscule établissant éventuellement un lien entre deux variables, ou une lettre répétée marquant un lien d'utilisation avec la variable portant cette lettre) ; utilisation préférentielle de certaines lettres selon la désignation : a, m, j ,s pour un ensemble année, mois, jour, semaine, k utilisé selon le cas en Integer pour un numéro de colonne, en String pour un caractère, en Variant pour une clé de dico...

Je ne vais pas poursuivre plus avant, mais il apparaît qu'un lien signficatif de désignation peut être parfaitement établi avec des noms très courts, tout aussi bien qu'avec des noms nettement plus longs, et je dois dire qu'ayant à l'occasion travaillé sur du code semblablement personnalisé mais sur des bases différentes des miennes, on parvient à s'assimiler assez rapidement l'économie du système et on s'y meut ensuite parfaitement à l'aise...

En espérant ne pas m'être trop longuement étendu...

Bonne journée.

edit avant de lâcher, vu le nombre de post intervenus...

Là où je déroge vraiment à ce qui paraît être un consensus (quasi donc) général, ce sont les commentaires !

Les commentaires ne sont jamais suffisants (même quand leur volume dépasse largement le volume du code), pour fournir toutes les explications nécessaires, et en ce qui me concerne ça m'empêche vraiment de lire le code !

Ce qu'on trouve le plus souvent c'est un paraphrasage censé indiquer la signification de la ligne, l'alternative, c'est d'apprendre VBA..., car de plus, s'il y a une subtilité elle a toute chance de ne pas être identifiée par le commentaire afférent ! Un exemple que j'ai eu vu de ce genre de choses : un demandeur n'arrivant pas à interpréter une ligne pourtant commentée, dont le commentaire ne faisait qu'indiquer ce que faisait la ligne, ce qui était d'ailleurs évident et se passait aisément de commentaires, seulement pour la lire (et l'interpréter), s'agissant d'une ligne de calcul, il fallait savoir que comportant une expression booléenne dans le calcul, celle-ci allait renvoyer -1 si True... Une fois l'explication fournie, hors commentaire, le demandeur n'avait plus de difficulté à interpréter le calcul !

Bref ! Je ne les trouve utiles que comme balises dans certaines procédures, sous forme d'un mot ou d'une expression aussi courte que possible, qui permet d'aller directement à cet emplacement...

Si je dois reprendre un code ancien fait par moi (je mettais quelques commentaires à mes débuts), je sais que je ne ferai pas l'économie d'une analyse dès lors que le code est un peu complexe et repose sur de multiples procédures, pour retrouver les centres de gravité de l'ensemble.

Les commentaires ne m'ont jamais rendu service, c'est pourquoi je m'en abstiens désormais, et les quelques fois (rares) où j'émets une procédure commentée à l'usage d'un demandeur (à sa demande), si je dois la lire à nouveau quelques temps après, je suis obligé de supprimer les commentaires pour y parvenir !

Je précise toutefois que je ne me trouve pas avare d'explications lorsqu'on m'en demande, je les fournis à part, et elles dépassent toujours largement le volume de code objet de l'explication.

Cordialement.

Rechercher des sujets similaires à "question bonnes pratiques codage"