Discussion :

[Edwige01]

Bonjour, après plusieurs recherches, je trouve des avis divergents sur la question.

Si je ne me trompe pas, la casse est faite uniquement pour améliorer la lisibilité d'un code en VBA car VBA n'est pas sensible à la casse comme le C# par ex (à confirmer).

Dans les règles que j'ai pu trouver sur le net, on évoque la casse camel pour tout ce qui est "Private" et la casse Pascal pour ce qui est "Public"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Sub test()   '   Ou Private Sub test()
Dim minEmploye as Integer
Const maxEmploye = 10
End Sub

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Public MinEmploye as Integer
Public Const MaxEmploye = 10

J'ai aussi vu que certaines personnes conseillaient de mettre toutes les constantes en majuscule.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Const MAXEMPLOYE = 10

Est-ce qu'un développeur a une réponse en ce qui concerne uniquement VBA?
Merci !

[Didier Gonard]

Bonjour,

Effectivement VBA n’est pas sensible à la casse, mais on se sert de conventions d’écritures pour augmenter la lisibilité du code, mais ce ne sont que des conventions et si les plus sont bien réels, ça n’influe en rien le comportement du code.

Je te listerai les plus grands principes, à suivre.

Cordialement,

Didier

[Edwige01]

Cool ! Merci beaucoup !

[Didier Gonard]

Bonjour,

VBA n’est donc pas sensible à la casse, Mais l’éditeur VBE la mémorise ce qui est très utile avec l’habitude.
Si tu prends en convention de notation le fait de nommer tes variables du genre : strMonNomdeClasseur quand tu tapes ton code après ta déclaration, tu fais exprès de ne taper tes variables et les mots clefs VBA (qui sont nommés du même genre) qu’en minuscule.
Du coup, dès que tu valideras la ligne l’éditeur identifiant les mots clefs et les variables déclarées (Option Explicit = merci) rectifieras automatiquement la casse de ta variable entrée… si tu l’as bien orthographiée, (sinon au lancement il te retournera une variable non définie), donc avec l’habitude tu détecteras le changement de casse automatique des variables et noms clefs et si ça ne se produit pas, tu réagiras tout de suite

La tendance sinon n’est pas je pense de différencier le Private du public, mais de suivre la ligne Microsoft, donc de se servir des majuscules pour découper visuellement les mots et selon la tendance suivie préfixer les variables avec 1 à 3 caractères en minuscules destinés à donner son type ou autre.

Penses aussi à l’IntelliSense qui t’expose les termes possibles après la frappe du point (VBA est en notation par point), mais aussi si tu frappes les premières lettres significatives de ta variable suivi de CTRL + Espace, il te valide ta variable direct si pas d’ambiguïté (serais le cas dans Sub gogo) ou te propose une liste de choix. Dans un code fourni, ça t’aides aussi du coup à te rappeler le nom de la variable (nombreux txtBox dans USF ect…) voulue surtout si tu as des habitudes de nommages constantes.

Le fait que VBA soit en anglais sinon est un avantage de lisibilité pour nous vu que ne pouvant employer les mots réservés, tu peux employer leur équivalent français ce qui nous est trivial. Prendre aussi l’habitude de ne pas utiliser les variables anglaises utilisées couramment par VBA en arguments dans ses procédures (évènementielles prédéfinies) et qui ne sont pas réservées comme Target pas exemple, mais d’employer Cible à la place dans tes créations propres.



Une fois la ligne validée, la casse se met en forme / idem déclaration sur la ligne de code :



cordialement,

Didier

[Edwige01]

Merci beaucoup pour ta réponse,

Effectivement j'utilise systématiquement l'option explicit et j'avais remarqué que la casse se modifiait automatiquement.

J'essaie de faire un récapitulatif des bonnes manières à suivre pour tous ceux qui veulent coder dans l'entreprise dans laquelle j'effectue mon stage.

Que conseillerais-tu pour la casse du coup? Tout en casse Pascal ou Casse Camel dont le début en minuscule informe du type?
Aucun mot en tout Majuscule ?
Peu importe si c'est publique ou privé et coder ainsi?
Vu qu'on a le choix je n'arrive pas à me décider...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Public MinEmploye as Integer
Public Const MaxEmploye = 10 
Dim MoyEmploye as Long
Const ChaineCaracteres as String

OU

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Public intMinEmploye as Integer
Public Const constMaxEmploye = 10 
Dim longMoyEmploye as Long
Const strChaineCaracteres as String

PS : J'ai lu cet article et il est stipulé qu'il est conseillé d'écrire les constantes en majuscule
http://plasserre.developpez.com/cour...ge=langage-vb5

[Didier Gonard]

Bonjour,

Ce sont 2 choses différentes, le fait de préfixer les noms est issu de la notation Hongroise (introduite par un Hongrois chez Xerox), Microsoft étant passé de 1 à 3 caractères de préfixes. Ensuite le CamelCase est effectivement l’emploi de majuscules pour la lisibilité des noms.

Il faut savoir que l’emploi de la notation hongroise comme beaucoup de choses est très controversé selon les différentes écoles, certains la considérant comme obsolète

Perso, je l’emploie ainsi que le CamelCase
Je ne fais pas de différence entre Public ou Privé. Il faut savoir que, vu son fonctionnement, en VBA on déclare généralement toutes ses variables en haut de container (module, procédure…) et que les variables publiques doivent obligatoirement être déclarée en haut d’un module Public. Une Pratique intéressante si tu en emploies plusieurs est de créer carrément un module ou ne sont déclarées et éventuellement initialisées que les variables public. Le recours à ses dernières est généralement limité au strict nécessaire en VBA.

Une fois l’habitude prise de ses notations et des possibilités de l’éditeur VBE (ancien…), ça va vite et c’est très facilement lisible.

Il faut associer à l’emploi de tout ça un outil indispensable qui est Mz-Tools 3.0 http://www.mztools.com/index.aspx un plus considérable à découvrir en détail car très riche, une de ses fonctionnalités très forte est son rechercher & rechercher-remplacer qui relègue celui du VBA au moyen-âge

Pour les constantes c’est en effet assez universel de les mettre en majuscule, donc je suis pour.

Je crois que ces principes de base, plus l’emploi (réfléchi) des commentaires est une bonne chose pour la pérennité du code intra-entreprise.

Le mieux est de s’adapter à la culture d’entreprise et si inexistante, la créer en prenant soin alors de créer une note / aide qui rapellera les conventions employées ainsi qu’une liste des principaux préfixes utilisés.

Vois cet article, que j’aime bien, en complément de celui que tu as cité : Descriptif des conventions typographiques du code Visual Basic

http://argyronet.developpez.com/office/vba/convention/

ainsi que cet article Microsoft :

http://support.microsoft.com/kb/173738/fr

PS : l'indentation est aussi à mettre en indispensable

cordialement,

Didier