CodeS-SourceS
Rechercher un code, un tuto, une réponse

Nomenclature : nommage des champs de base de donnée, et des variables

Octobre 2017


Nomenclature : nommage des champs de base de donnée, et des variables



C'est quoi ?


C'est l'ensemble des règles de nommage qui permet de ne pas se noyer dans une appli, quelle qu'elle soit.
C'est ma manière de travailler, et elle est fluide à l'usage, même pour les autres participants. Il faut juste prévoir un peu. Mais c'est indispensable en Info...

BdD

Sur le nom des tables


Peu de choses, juste ajouter un préfixe relatif à l'utilisation des tables.
Les tables de Références (liste de trucs, etc.) : préfixe : REF_
Celles de Fonctionnement (messagerie, table des traductions en site multi-lingue, etc.) : préfixe FON_
Toutes les autres, sont normalement les tables centrales de l'utilisation de l'appli, pas de préfixe.


Ne pas oublier pour le nom de la table, qu'il n'y a que 26 lettres dans l'alphabet, et rares sont les tables ZORRO ou XYLOPHENE. Par contre, y'a beaucoup de P (PERSONNAGE, PERSONNEL, PERSONNE, FON_PROFIL, REF_PAYS, etc.). Autant que faire ce peut, au regard de la règle de nommage des champs, éviter les initiales identiques (sauf pour des types de table différents).


Avantages :
- D'un coup d'oeil vous savez retrouvez votre table dans le BO de la BdD.
- Lors de la création d'une requête, vous savez quelle est le nom de la table a utiliser.

Inconvénient :
Il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après.

Les champs


Là il y a du boulot.


A peu de chose près toujours avoir dans une table :
- un champ ID, clef primaire unique en auto-incrément.
- un champ LIB, qui fini toujours par avoir son utilité (liste, BO, etc.)
- puis les autres?

Nommage : préfixer les champs par les initiales de la table :
- P_ID, pour l'id de la table PAGE
- R_P_LIB, pour le libellé de la table de référence REF_PAYS
- F_P_DATEIN, pour la date de la table de fonctionnement FON_MESSAGE

Avantages :
- Lors de la création d'une requête en cours de dév., vous ne pouvez plus avoir de doute sur le champs à appeler.
- SQL ne s'emmêlera pas les pinceaux entre ID et ID (celui de USER et celui de FON_CONNEXION).

Inconvénient :
Il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après.

PHP


(et autres ?)
Le préfixe ça marche, on continue donc.
Comme vous ne pouvez pas toujours connaître (ou contrôler) l'état de REGISTER_GLOBAL de votre hébergeur, autant prendre ses précautions pour éviter que $_SESSION['nom' * prenne la valeur de $nom...

Donc :
  • variable de session : préfixe 's_'
  • variable passée en get : préfixe 'g_'
  • variable passée en post : préfixe 'p_'
  • autres, vous aurez compris,
  • variable courantes : ne pas avoir des noms trop long, mais faire un nommage selon l'usage de l'objet manié. Différence en $cout (de l'article) et $cout (de mon panier). Si j'ai ce cas de figure, autant tout de suite les nommer $cout_art et $cout_pan.


Avantage :
Lors de la création d'une requête ou d'un test en cours de dév., vous savez toujours quel est le nom de la variable à utiliser.

Inconvénient :
Là encore il faut y réfléchir avant. Mais est-ce un inconvénient au vu du temps gagné après, surtout en recherche de debug lié à un conflit de nom de variable


Voilà, sans prétention. Evident pour moi, mais apparemment pas pour tout le monde...

Tartuffe
Publié par cs_Tartuffe.
Ce document intitulé «  Nomenclature : nommage des champs de base de donnée, et des variables  » issu de CodeS-SourceS (codes-sources.commentcamarche.net) est mis à disposition sous les termes de la licence Creative Commons. Vous pouvez copier, modifier des copies de cette page, dans les conditions fixées par la licence, tant que cette note apparaît clairement.
Les sessions php, comment ça marche ?
Utiliser les itérateurs en php5