Je viens d'=E9crire ceci dans un autre fil. J'ai promis de voir si je=20
trouverais les r=E9f=E9rences, mais je crains de ne gu=E8re =EAtre effica=
ce sur=20
le coup.
Quelqu'un assurera-t-il mieux ?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Une recherche sur "Ms-Access r=E8gles de nommage" serait s=FBrement utile=
,=20
bien que les r=E9sultats ne soient pas imm=E9diats, je viens de regarder.=
Je vais t=E2cher (sans dire quand) de trouver les r=E9f=E9rences quelque =
part=20
(si quelqu'un vient =E0 la rescousse je ne serai pas vex=E9 ;) ).
Chaque objet (table, formulaire, requ=EAte, contr=F4le ...) doit porter u=
n=20
nom qui commence par un pr=E9fixe de trois lettres d=E9signant sa cat=E9g=
orie.
Ainsi, les noms des formulaires commenceront par frm, les noms des=20
tables par tab, les noms des requ=EAtes par req (ou qry, de pr=E9f=E9renc=
e le=20
m=EAme pr=E9fixe dans toute la base), les noms des =E9tiquettes par lbl, =
les=20
noms des zones de saisie texte par txt, les noms des listes d=E9roulantes=
=20
modifiables par mod, ceux des listes ordinaires par lst, ainsi de suite.
Pas d'espace, de caract=E8re accentu=E9 ni de signe de ponctuation dans l=
es=20
noms. Des majuscules peuvent d=E9limiter les mots, comme=20
tabCategorieMateriaux pour la table des cat=E9gories de mat=E9riaux.
Il sera ainsi plus facile de lire=20
Forms!frmDevis!frmLignesDevisMat!intCategorieMat, qui permet de savoir=20
qu'on doit chercher, parmi les formulaires principaux, un formulaire=20
frmDevis, avec un sous-formulaire qui s'appelle frmLignesDevisMat (c'est =
une bonne id=E9e de donner au sous-formulaire le m=EAme nom qu'au formula=
ire=20
sur lequel il est bas=E9), on s'attendrait =E0 trouver dans le=20
sous-formulaire les lignes du devis de mat=E9riaux apparaissant dans le=20
formulaire principal, et on saurait qu'on peut y trouver un entier=20
contenant un num=E9ro de cat=E9gorie de mat=E9riaux. Avec=20
Forms!frmDevis!frmLignesDevisMat!txtCategorieMat, on saurait que ce=20
num=E9ro appara=EEt dans une zone de saisie texte (ce qui n'impliquerait =
pas=20
forc=E9ment qu'on puisse modifier le num=E9ro, si il s'agit d'un num=E9ro=
auto=20
par exemple).
Il peut =EAtre parfois utile d'abr=E9ger les noms de tables, comme=20
tabCategMat. En effet, il peut un jour =EAtre d=E9cid=E9 de migrer la bas=
e sur=20
une autre plateforme. Les noms des objets sous Oracle, par exemple, ne=20
peuvent =EAtre plus longs que 30 caract=E8res.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
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 ;-)
"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 ...
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 ;-)
"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.
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 ;-)
"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
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" a écrit dans le message de news:
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 ...
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" <gloops@niark.invalid> a écrit dans le message de news:
uzHCyE4YIHA.1184@TK2MSFTNGP04.phx.gbl...
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.
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" a écrit dans le message de news:
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
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 ...
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=2509&sid=618
http://support.microsoft.com/?scid=kb%3Ben-us%3B826763&x=11&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 ...
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
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.
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.
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
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...
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...
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...
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 ?
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.
"Gloops" <gloops@niark.invalid> a écrit dans le message de news:
eZUHTnFZIHA.1204@TK2MSFTNGP03.phx.gbl...
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 ?
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
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 ?
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 ------------ -")
