Règles de nommage

Le
Gloops
Bonjour tout le monde,

Je viens d'écrire ceci dans un autre fil. J'ai promis de voir si je
trouverais les références, mais je crains de ne guère être effica=
ce sur
le coup.

Quelqu'un assurera-t-il mieux ?

=
==
=
Une recherche sur "Ms-Access règles de nommage" serait sûrement utile=
,
bien que les résultats ne soient pas immédiats, je viens de regarder.=


Je vais tâcher (sans dire quand) de trouver les références quelque =
part
(si quelqu'un vient à la rescousse je ne serai pas vexé ;) ).

Chaque objet (table, formulaire, requête, contrôle ) doit porter u=
n
nom qui commence par un préfixe de trois lettres désignant sa catég=
orie.
Ainsi, les noms des formulaires commenceront par frm, les noms des
tables par tab, les noms des requêtes par req (ou qry, de préférenc=
e le
même préfixe dans toute la base), les noms des étiquettes par lbl, =
les
noms des zones de saisie texte par txt, les noms des listes déroulantes=

modifiables par mod, ceux des listes ordinaires par lst, ainsi de suite.

Pas d'espace, de caractère accentué ni de signe de ponctuation dans l=
es
noms. Des majuscules peuvent délimiter les mots, comme
tabCategorieMateriaux pour la table des catégories de matériaux.

Il sera ainsi plus facile de lire
Forms!frmDevis!frmLignesDevisMat!intCategorieMat, qui permet de savoir
qu'on doit chercher, parmi les formulaires principaux, un formulaire
frmDevis, avec un sous-formulaire qui s'appelle frmLignesDevisMat (c'est =

une bonne idée de donner au sous-formulaire le même nom qu'au formula=
ire
sur lequel il est basé), on s'attendrait à trouver dans le
sous-formulaire les lignes du devis de matériaux apparaissant dans le
formulaire principal, et on saurait qu'on peut y trouver un entier
contenant un numéro de catégorie de matériaux. Avec
Forms!frmDevis!frmLignesDevisMat!txtCategorieMat, on saurait que ce
numéro apparaît dans une zone de saisie texte (ce qui n'impliquerait =
pas
forcément qu'on puisse modifier le numéro, si il s'agit d'un numéro=
auto
par exemple).

Il peut être parfois utile d'abréger les noms de tables, comme
tabCategMat. En effet, il peut un jour être décidé de migrer la bas=
e sur
une autre plateforme. Les noms des objets sous Oracle, par exemple, ne
peuvent être plus longs que 30 caractères.

En espérant aider
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
3stone
Le #6344401
Salut,

Tu es trop long pour que je réponde "dessous" ;-)


Un peu de lecture...
http://www.mvps.org/access/general/gen0012.htm
http://support.microsoft.com/kb/286335/fr?spid%09&sida8
http://support.microsoft.com/?scid=kb%3Ben-us%3B826763&x&y=8

Pour les formulaires et sous formulaires, perso je préfère :

frmDevis et frmDevisDetail ce qui les placent l'un sous l'autre dans
la fenêtre d'Access... au contraire de frmDevis et frmDetailDevis.

Comme beaucoup, je n'utilise jamais d'espace, ni de caractère accentué.
Toujours écrire les expressions en anglais, même si Access les traduits ;-)

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)





"Gloops"
Je viens d'écrire ceci dans un autre fil. J'ai promis de voir si je
trouverais les références, mais je crains de ne guère être efficace sur
le coup.

Quelqu'un assurera-t-il mieux ?

================================================================ Une recherche sur "Ms-Access règles de nommage" serait sûrement utile,
bien que les résultats ne soient pas immédiats, je viens de regarder.

Je vais tâcher (sans dire quand) de trouver les références quelque part
(si quelqu'un vient à la rescousse je ne serai pas vexé ;) ).

Chaque objet (table, formulaire, requête, contrôle ...) doit porter un
nom qui commence par un préfixe de trois lettres désignant sa catégorie.
Ainsi, les noms des formulaires commenceront par frm, les noms des
tables par tab, les noms des requêtes par req (ou qry, de préférence le
même préfixe dans toute la base), les noms des étiquettes par lbl, les
noms des zones de saisie texte par txt, les noms des listes déroulantes
modifiables par mod, ceux des listes ordinaires par lst, ainsi de suite.

Pas d'espace, de caractère accentué ni de signe de ponctuation dans les
noms. Des majuscules peuvent délimiter les mots, comme
tabCategorieMateriaux pour la table des catégories de matériaux.

Il sera ainsi plus facile de lire
Forms!frmDevis!frmLignesDevisMat!intCategorieMat, qui permet de savoir
qu'on doit chercher, parmi les formulaires principaux, un formulaire
frmDevis, avec un sous-formulaire qui s'appelle frmLignesDevisMat (c'est
une bonne idée de donner au sous-formulaire le même nom qu'au formulaire
sur lequel il est basé), on s'attendrait à trouver dans le
sous-formulaire les lignes du devis de matériaux apparaissant dans le
formulaire principal, et on saurait qu'on peut y trouver un entier
contenant un numéro de catégorie de matériaux. Avec
Forms!frmDevis!frmLignesDevisMat!txtCategorieMat, on saurait que ce
numéro apparaît dans une zone de saisie texte (ce qui n'impliquerait pas
forcément qu'on puisse modifier le numéro, si il s'agit d'un numéro auto
par exemple).

Il peut être parfois utile d'abréger les noms de tables, comme
tabCategMat. En effet, il peut un jour être décidé de migrer la base sur
une autre plateforme. Les noms des objets sous Oracle, par exemple, ne
peuvent être plus longs que 30 caractères.

En espérant aider ...
Jac
Le #6344371
Bonjour Gloops,

ce que tu annonces correspond à la vision académique, mais moi,
j'y entrevois quelques variantes.

Je pense que ton préfixe de trois lettres n'est pas forcément nécessaire car
dans Access, chaque catégorie d'objet est rangée dans son conteneur : les
requêtes ne sont pas mélangées avec les formulaires qui ne le sont pas avec
les états, macros, modules et autres tables.
Donc si je cherche une requête, c'est dans le conteneur à requêtes qu'elle
se trouve, donc aucun risque de confondre avec un formulaire ou une table.
Quand tu vas acheter des pâtes, tu ne vas pas les chercher dans le rayon des
boissons.

Pour ce qui est des tables, je les écris toujours en majuscules. Donc
visuellement, à toutes fins utiles, elles se différencient des requêtes.

Si j'attache des tables dans un frontal et qu'elles proviennent de
plusieurs mdb, toutes les tables d'un même mdb commencent par le même
chiffre (quand je peux le faire, bien sûr, car parfois les héritages peuvent
sembler indigestes...), car quand on est dans le gestionaire de tables
liées, étant donné que la fenêtre n'a pas d'ascenseur horizontal et qu'elle
est toujours dimentionnée pour ceux qui utilisent un écran 12 pouces acheté
du temps du dos, c'est plus facile à sélectionner si elles commencent par 1,
2 ou 3 (ex: 3CLIENT, 3VILLES, ...). C'est sûr que si le chemin d'accès est
court (C:Factures) il n'y a pas de problème, mais dans une arborescence de
réseau, pour lire le nom du conteneur de tables, il vaut mieux ne pas avoir
été embauché la veille...

Si non, moi, j'ai pris l'habitude, et je n'en démords pas, de commencer le
nommage de tous les autres objets par quelques chiffres. Les 2 premiers me
permettent de les ranger par catégorie, car l'ordre alpha naturel éloigne
beaucoup les frères et cousins : CumulFacture se retrouvent au milieu des
CategorieClient et autres CumulFournisseur, RecapFacture est dans les "R",
TotalFacture dans les "T". C'est vrai qu'on peu mettre facture au début :
FactureCumul, FactureRecap et FactureTotal.

Donc pour moi, tout ce qui concerne les factures, que ce soit en requêtes,
formulaires, états d'impression, macros, boutons sur un menu général
pourrait commencer par exemple, par 20 :
20-1-ListeDeToutesLesFactures
20-2-ListeDesFacturesDuneAnnee
21-1-ChiffreDaffaireParCommande
21-2-TotalHtParFacture
22-1-TotalHtParClient
...
26-TotalHtGlobal

Les objets concernant les clients commencent par 10
10-ClientsTous
11-ClientsDeQuelPays

Impression des factures
711-FacturesEmises_AvecSolde
7121-FacturesEmises_SansSolde
7122-FacturesEmises_SansSolde_Groupe
7123-FacturesEmises_SansSolde_HT

Les formulaires et sous formulaires :
41-1-0-Commandes-formulaire
41-1-1-DetailCommandes-SousFormulaire

Et je mets aussi des séparateurs qui sont des requêtes, formulaires ou états
vides mais dont l'intitulé agit comme un titre :
10 _____ CLIENTS ...........................
20 _____ FACTURES .........................
40 _____ TARIFS .............................
80 _____ RECETTES .........................

Ce qui m'a inspiré pour imaginer ces séparateurs dans Access, c'est les
commentaires que je mets dans les macros pour délimiter certaines actions.
C'est pratique pour trouver où commence une étape. Donc ici pour regrouper
tout ce qui concerne clients, factures, tarifs ou recettes.

Parfois j'y vais aussi avec des sous-groupes :
70 ___ FACTURES IMPRESSION-----------------,
71 ___ Factures émises--------------------,
75 ___ FACTURES RÉSULTATS --------------------
Ici accents, espaces, ..., je me permets tout car ça ne sert à rien d'autre
qu'à délimiter les "trucs" qui vont ensemble.

Et souvent, comme par hazard, formulaire et état commencent par
les mêmes chiffres que la requête sur laquelle ils s'appuient. Je trouve
ça bien pratique car quand on replonge dedans au bout de quelques mois,
ça me semble plus facile.

On en reparle quand tu veux.

Jac

"Gloops"
Bonjour tout le monde,

Je viens d'écrire ceci dans un autre fil. J'ai promis de voir si je
trouverais les références, mais je crains de ne guère être efficace sur
le coup.

Quelqu'un assurera-t-il mieux ?

================================================================ Une recherche sur "Ms-Access règles de nommage" serait sûrement utile,
bien que les résultats ne soient pas immédiats, je viens de regarder.

Je vais tâcher (sans dire quand) de trouver les références quelque part
(si quelqu'un vient à la rescousse je ne serai pas vexé ;) ).

Chaque objet (table, formulaire, requête, contrôle ...) doit porter un
nom qui commence par un préfixe de trois lettres désignant sa catégorie.
Ainsi, les noms des formulaires commenceront par frm, les noms des
tables par tab, les noms des requêtes par req (ou qry, de préférence le
même préfixe dans toute la base), les noms des étiquettes par lbl, les
noms des zones de saisie texte par txt, les noms des listes déroulantes
modifiables par mod, ceux des listes ordinaires par lst, ainsi de suite.

Pas d'espace, de caractère accentué ni de signe de ponctuation dans les
noms. Des majuscules peuvent délimiter les mots, comme
tabCategorieMateriaux pour la table des catégories de matériaux.

Il sera ainsi plus facile de lire
Forms!frmDevis!frmLignesDevisMat!intCategorieMat, qui permet de savoir
qu'on doit chercher, parmi les formulaires principaux, un formulaire
frmDevis, avec un sous-formulaire qui s'appelle frmLignesDevisMat (c'est
une bonne idée de donner au sous-formulaire le même nom qu'au formulaire
sur lequel il est basé), on s'attendrait à trouver dans le
sous-formulaire les lignes du devis de matériaux apparaissant dans le
formulaire principal, et on saurait qu'on peut y trouver un entier
contenant un numéro de catégorie de matériaux. Avec
Forms!frmDevis!frmLignesDevisMat!txtCategorieMat, on saurait que ce
numéro apparaît dans une zone de saisie texte (ce qui n'impliquerait pas
forcément qu'on puisse modifier le numéro, si il s'agit d'un numéro auto
par exemple).

Il peut être parfois utile d'abréger les noms de tables, comme
tabCategMat. En effet, il peut un jour être décidé de migrer la base sur
une autre plateforme. Les noms des objets sous Oracle, par exemple, ne
peuvent être plus longs que 30 caractères.

En espérant aider ...
Gloops
Le #6344201
3stone a écrit, le 30/01/2008 23:57 :
Salut,

Tu es trop long pour que je réponde "dessous" ;-)


Très bien observé.



Un peu de lecture...
http://www.mvps.org/access/general/gen0012.htm
http://support.microsoft.com/kb/286335/fr?spid%09&sida8
http://support.microsoft.com/?scid=kb%3Ben-us%3B826763&x&y=8



J'ai bien fait de ne pas chercher : j'aurais passé un temps précieux à
peut-être ne pas trouver, là où d'autres ont les idées plus clair es.

Pour les formulaires et sous formulaires, perso je préfère :

frmDevis et frmDevisDetail ce qui les placent l'un sous l'autre dans
la fenêtre d'Access... au contraire de frmDevis et frmDetailDevis.


Effectivement, c'est une bonne idée de les regrouper. J'aurais tendance
à considérer Detail comme un mot réservé (il y a si je ne m'abuse une
section qui s'appelle comme ça), et je proposerais frmDevisLigne


Comme beaucoup, je n'utilise jamais d'espace, ni de caractère accentu é.


Surtout qu'il faut plusieurs doigts pour ajouter des crochets avant et
après le nom, et qu'un développement se fait parfois en temps limité .

Toujours écrire les expressions en anglais, même si Access les trad uits ;-)



Oui, on a d'ailleurs lu ici que ça a donné à plus d'un et d'une
l'occasion de s'arracher des cheveux ...

Gloops
Le #6344191
Jac a écrit, le 31/01/2008 00:36 :
Parfois j'y vais aussi avec des sous-groupes :
70 ___ FACTURES IMPRESSION-----------------,
71 ___ Factures émises--------------------,
75 ___ FACTURES RÉSULTATS --------------------



Il est vrai que ça présente l'intérêt de la clarté dans les lis tes
d'objets. ça me convainc plus que le paquet de pâtes qui traîne dan s les
surgelés (et hélas on voit aussi l'inverse ;) ). On dit bien pourtant
qu'un produit dangereux ne doit pas être conditionné dans un emballag e
de produit alimentaire, et inversement.

Cela étant, il faut bien se rappeler qu'on doit ajouter onze tirets et
pas douze ni dix, j'imagine que tu dois souvent avoir à procéder par
copier/coller ?

Je dirais bien que les noms d'objets doivent être clairs et faciles à
taper pour le programmeur (et surtout pour ses successeurs), et
l'interface claire pour l'utilisateur.

3stone
Le #6344151
re,

"Gloops"
[...]
Pour les formulaires et sous formulaires, perso je préfère :

frmDevis et frmDevisDetail ce qui les placent l'un sous l'autre dans
la fenêtre d'Access... au contraire de frmDevis et frmDetailDevis.


| Effectivement, c'est une bonne idée de les regrouper. J'aurais tendance
| à considérer Detail comme un mot réservé (il y a si je ne m'abuse une
| section qui s'appelle comme ça), et je proposerais frmDevisLigne


Si Detail "pourrait" être un nom réserve, frmDevisDetail ne l'est pas
avec certitude ;-)

Quant à la désignation de la section du style Me.Détail.BackColor...
je n'utilise pas ce nommage non plus ;-)
Car selon les versions d'Access, c'est Detail ou Détail avec l'accent :-(
Donc, Me.Section(acDetail) ou Me.Section(0) est autrement plus portable...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Gloops
Le #6343881
3stone a écrit, le 01/02/2008 00:17 :
Donc, Me.Section(acDetail) ou Me.Section(0) est autrement plus portable ...



Pour sûr.
Je me dis quand même qu'on n'est jamais trop méfiant ni trop clair.

Jac
Le #6343861
En fait, je ne rajoute pas 10 ou 11 ou 12 tirets.
J'en rajoute ce qu'il faut pour que, visuellement,
ils fassent pratiquement tous la même longueur.

70 ___ FACTURES IMPRESSION ------------------
71 ___ Factures émises --------------------------------
75 ___ FACTURES RÉSULTATS --------------------


"Gloops"
Jac a écrit, le 31/01/2008 00:36 :
Parfois j'y vais aussi avec des sous-groupes :
70 ___ FACTURES IMPRESSION-----------------,
71 ___ Factures émises--------------------,
75 ___ FACTURES RÉSULTATS --------------------


Cela étant, il faut bien se rappeler qu'on doit ajouter onze tirets et
pas douze ni dix, j'imagine que tu dois souvent avoir à procéder par
copier/coller ?

Gloops
Le #6343791
Jac a écrit, le 01/02/2008 12:40 :
En fait, je ne rajoute pas 10 ou 11 ou 12 tirets.
J'en rajoute ce qu'il faut pour que, visuellement,
ils fassent pratiquement tous la même longueur.



ça aide vraiment, dans un module, quand tu tapes

Set Rs = CurrentDb().OpenRecordset("1-2-3 Factures du mois ------------ -")

à savoir quand il faut fermer le guillemet ?

Publicité
Poster une réponse
Anonyme