Bonnes pratiques de nommage des champs

  • Bonnes pratiques de nommage des champs

    Posté par Sebastien sur 30 septembre 2022 à 12h41

    Bonjour à tous.

    Je suis sur le point de recréer plusieurs environnements avec mes collègues et je voulais faire un petit “sondage” sur les pratiques de nommage que vous utilisez pour les champs Dataverse (Pour un post similaire sur les contrôles PowerApps cliquez ici ). J’ai commencer à mettre en place une série de règles pour mon entreprise, les voici :

    Nom de schéma

    1. Séparateur “_” entre chaque mot

    2. Majuscule au début de chaque mot

    3. Pas de “et”, “de”, “le”, etc…

    4. Ajout d’un suffixe qui commence par une minuscule

    Suffixes en fonction du type

    Texte _text

    Texte multiligne _multiText

    Texte enrichi _richText

    URL _url

    Téléphone _phone

    E-mail _email

    Entier _int

    Décimal _dec

    Flottant _float

    Durée _time

    Fuseau horraire _tmz

    Code de langue _lang

    Booléen _bool

    OptionSet _option

    MultiSelect _options

    Devise _euro

    Rechercher _lookUp

    Date _date

    Date & heure _dateTime

    Numérotation automatique _autoNum

    Fichier _file

    Image _img

    __________________________________________________________

    Exemples :

    Nom d’affichage : Accompte de réservation

    Type : Devise

    Accompte_Réservation_euro

    Nom d’affichage : Commentaire sur l’installation

    Type : Multiligne

    Commentaire_Installation_multiText

    En attente de vos avis !

    Bonne journée.

    PostID=Bcjo0E7y9lwWty4

    Tanguy Touzard a répondu Il y a 4 mois, 2 semaines 1 Membre · 4 Réponses
  • 4 Réponses
  • DavidZed

    Membre
    30 septembre 2022 à 13h15

    Hello Sebastien Brandeis ,

    Pour Dataverse, mettre en place des règles de nommage sur le ‘shema name’ présente assez peu d’intérêt, voire peut se révéler handicapant dans certains cas.

    Exemple quand tu te retrouves à devoir manipuler les colonnes dans l’pp studio avec des showcolumns / dropcolumns etc… il est très pratique de pouvoir déduire le shema name facilement (Préfixe de l’éditeur + display Name sans les espaces et caractères spéciaux)

    CommentID=4b3HTOkHD9cDrN2, PostID=Bcjo0E7y9lwWty4

  • Alexandre

    Membre
    1 octobre 2022 à 20h53

    Mes champs je les nomme en parfait français (cible app uniquement francophone) mais je n’oublie de jeter un oeil sur le nom technique qui en découlera pour qu’il soit intelligent et cohérent (simple à retrouver, comme le précise DavidZed .

    C’est un gain de temps énorme quand tu vas mettre un formulaire puisque les étiquettes porteront le nom de tes champs.

    CommentID=BQh8fkDWvt9a19D, PostID=Bcjo0E7y9lwWty4

  • R3dKap

    Membre
    4 octobre 2022 à 20h03

    Sebastien Brandeis, de mon côté, sur Dataverse :

    • Au moment de créer ma solution je crée un éditeur dont le préfixe est parlant pour la solution concernée

    Ainsi, je sais déjà que tous les noms de schéma de mes objets commenceront par ce préfixe suivis d’un “_”.

    • Ensuite tout est en minuscule avec des “_” pour séparer les mots et essayant d’être le plus parlant possible (j’ai ouï dire que les minuscules étaient recommandées par MS)

    Du coup, comme le souligne DavidZed, c’est très facile à retrouver dans l’éditeur Power Apps lors de l’utilisation des fonctions du type ShowColumns().

    Et pour moi, pas besoin d’avoir l’info du type de données dans le nom du schéma… Mais ce n’est qu’un avis perso…

    CommentID=eRkg1kIq589DyEC, PostID=Bcjo0E7y9lwWty4

  • Tanguy Touzard

    Membre
    6 octobre 2022 à 7h10

    Si on essaye de suivre les nomenclatures de Microsoft dans Dataverse, il faudrait plutôt écrire les noms en PascalCase (sans compter le préfixe), ce qui donnera le nom de schéma. Le nom logique sera automatiquement remis en minuscule. Pourquoi me direz-vous? il existe cette notion de Early Bound Entities qui sert à générer le modèle objet CRM en .Net pour les développeurs et qui reprend le nom de schéma. Donc si vous utilisez du PascalCase, vous aurez des noms de classes (table) et propriétés (colonnes) respectant les bonnes pratiques de nommage .Net, en plus d’avoir une cohérence pour le low code/no code.

    Ensuite, en suivant toujours la logique de ce que fait MS (quand ils le font bien), certains type de champ doivent être préfixé/suffixé:

    • Lookup : doit finir par Id => prefix_TableLieeId

    • Choix : doit finir par Code => prefix_MaListeCode

    • Booléen : doit représenter une affirmation => prefix_EstAcceptee

    • Date : contient le mot Date ou fait référence à une action => prefix_DateDebut ou prefix_SigneLe

    Pour les autres types, le nommage en lui-même devrait suffire à identifier le type.

    Voilà, c’est ma petite expérience de 19 ans de Dynamics CRM/365 en tant que développeur principalement mais aussi de citizen developer maintenant 🙂

    CommentID=mALztDI0zC5iij9, PostID=Bcjo0E7y9lwWty4

Connectez-vous pour répondre.