Partager via


Lisibilité du code

La lisibilité du code est un aspect important du développement d’applications qui est souvent négligé. Le code lisible est plus facile à comprendre, à gérer et à déboguer.

Conventions de dénomination

Les conventions d’affectation de noms cohérentes améliorent considérablement la lisibilité de votre code. Il vous aide à identifier rapidement l’objectif de chaque élément de votre application et facilite la navigation dans votre codebase.

Conventions de dénomination générales

Cette section décrit les conventions de dénomination « camelCase » et « PascalCase ». Si vous connaissez déjà ces termes, vous pouvez passer à la section suivante.

Casse chameau

Utilisez le camelCase pour les contrôles et les variables. La casse "camel case" commence par un préfixe en minuscule, supprime tous les espaces des noms d'objets ou de variables, et met en majuscule la première lettre de chaque mot suivant. Par exemple, un contrôle de saisie de texte peut être nommé txtUserEmailAddress.

Casse Pascal

Utilisez la casse Pascal pour les sources de données. Le cas Pascal est parfois appelé « cas chameau supérieur ». Comme le camel case, il supprime tous les espaces et met une majuscule à la première lettre des mots. Cependant, contrairement au camel case, le Pascal case met également en majuscule le premier mot. Par exemple, une source de données commune dans Power Apps est le connecteur Utilisateurs Microsoft Office 365, nommé Office365Users dans le code.

Noms d’écran

Choisissez les noms d’écran qui affichent clairement l’objectif de l’écran, ce qui facilite la navigation dans les applications complexes dans Power Apps Studio.

Les lecteurs d’écran lisent à haute voix les noms d’écran. Les utilisateurs ayant des besoins en matière d’accessibilité de la vision s’appuient sur ces lecteurs d’écran. Utilisez un langage simple pour les noms d’écran, incluez des espaces et évitez les abréviations. Terminez chaque nom par le mot « Écran » pour fournir un contexte clair lorsque le nom est annoncé.

Voici quelques exemples pertinents :

  • Home_Screen ou Home Screen
  • Search_Screen ou Search Screen

Capture d’écran montrant une liste de noms d’écran qui suivent le modèle décrit.

Ces exemples de noms d’écran sont moins compréhensibles :

  • Home
  • LoaderScreen
  • EmpProfDetails
  • Thrive Help

Noms de contrôle

Utilisez CamelCase pour tous les noms de contrôle sur le canvas. Commencez par un descripteur de type trois caractères, suivi de l’objectif du contrôle. Cette approche permet d’identifier le type de contrôle et facilite la création de formules et la recherche. Par exemple, lblUserName indique que le contrôle est une étiquette.

Le tableau suivant présente les abréviations des contrôles courants.

Nom du contrôle Abréviation
Badge bdg
Bouton btn
Contrôle Caméra caméra
Canevas peut
Carte crd
Graphiques chr
Case à cocher vérif
Collection colonne
Boîte combinée cmb
Composant cmp
Conteneur con
Les dates dte
Liste déroulante drp
Formulaire frm
Galerie gal
Groupe grp
En-tête HDR
Texte HTML htm
Icône ico
Image img
Bouton d’informations Informations
Étiquette lbl
Lien lnk
Zone de liste lst
Microphone micro
Microsoft Stream str
Forme d’une section de page sec
Saisie effectuée à l’aide du stylet stylo
Tuile Power BI pbi
Barre de progression pbar
Classement rtg
Éditeur de texte enrichi rte
Formes (rectangle, cercle, etc.) shp
Curseur sld
Liste d’onglets tab
Tableau tbl
Saisie de texte txt
Minuteur tmr
Bascule tgl
Vidéo vid

La liste détaillée des contrôles et de leurs propriétés est décrite dans Référence des contrôles.

Note

Les noms de contrôle doivent être uniques dans une application. Si un contrôle est réutilisé sur plusieurs écrans, le nom abrégé de l’écran doit avoir un suffixe. Par exemple, galBottomNavMenuHS, où « HS » signifie « Écran d’accueil ». Cette approche facilite la référence au contrôle dans les formules entre les écrans.

Voici quelques exemples incorrects :

  • zipcode
  • Next

Lorsque vous nommez de manière cohérente vos contrôles, votre application est plus propre dans la vue de navigation, tout comme votre code.

Capture d’écran de la vue de navigation montrant les noms de contrôle en suivant le modèle décrit.

Noms de la source de données

Lorsque vous ajoutez une source de données à votre application, vous ne pouvez pas modifier le nom dans l’application Power Apps. Le nom est hérité du connecteur source ou des entités de données dérivées de la connexion.

En voici quelques exemples :

  • Nom hérité du connecteur source : Le connecteur Utilisateurs Office 365 est nommé Office365Users dans votre code.
  • Entités de données dérivées de la connexion : une liste Microsoft SharePoint nommée Employees est renvoyée par le connecteur SharePoint. Par conséquent, le nom de la source de données dans votre code est Employees. La même application Power Apps peut également utiliser le même connecteur SharePoint pour accéder à une liste SharePoint nommée Contractors. Dans ce cas, le nom de la source de données dans le code est Contractors.

En savoir plus sur les connecteurs et les connexions dans Vue d’ensemble des connecteurs pour les applications de canevas.

Connecteurs d’action standard

Dans les connecteurs d’action standard qui exposent des fonctions, comme LinkedIn, le nom de la source de données et ses opérations utilisent la casse Pascal. Par exemple, la source de données LinkedIn est nommée LinkedIn et a une opération nommée ListCompanies.

ClearCollect(
    colCompanies,
    LinkedIn.ListCompanies()
)

Connecteurs personnalisés

Utilisez des connecteurs personnalisés pour vous connecter à des interfaces de programmation d’applications personnalisées, telles que des services ou des API métier créées par votre entreprise. Tout créateur de votre environnement peut créer des connecteurs personnalisés. Utilisez la casse Pascal pour le nom de la source de données et ses opérations. Le nom du connecteur personnalisé et la façon dont il apparaît dans Power Apps peut différer.

Prenons cet exemple d’un connecteur personnalisé nommé MS Auction Item Bid API.

Capture d’écran d’un connecteur nommé API Ms Auction Item Bid.

Lorsque vous créez une connexion à partir de ce connecteur et que vous l’ajoutez à votre application Power Apps en tant que source de données, elle apparaît sous la forme AuctionItemBidAPI.

Capture d’écran d’un connecteur montrant que le nom est AuctionItemBidAPI.

Pour découvrir la raison, examinez le fichier OpenAPI pour obtenir un attribut de titre qui contient le texte Auction Item Bid API.

"info": {
    "version": "v1",
    "title": "Auction Item Bid API"
},

Power Apps supprime tous les espaces de cette valeur d’attribut et l’utilise comme nom de votre source de données.

Astuce

Remplacez la valeur de cet attribut par un nom au format Pascal tel que AuctionItemBidAPI et utilisez-le comme nom de votre connexion personnalisée. De cette façon, il n’y a aucune confusion. Modifiez cette valeur avant d’importer le fichier OpenAPI pour créer le connecteur personnalisé.

Note

Si vous utilisez l’option Créer à partir d’une option vide au lieu d’importer un fichier OpenAPI existant, Power Apps vous invite à entrer le nom du connecteur personnalisé. Ce nom est à la fois le nom du connecteur personnalisé et la valeur de l’attribut de titre à l’intérieur du fichier OpenAPI. Utilisez un nom pascal comme AuctionItemBidAPI pour maintenir la cohérence et la simplicité des choses.

Tables de données Excel

Power Apps utilise des DataTables dans Microsoft Excel pour se connecter aux données dans les feuilles de calcul Excel. Gardez ces points à l’esprit lorsque vous créez des documents Excel comme sources de données :

  • Donnez des noms descriptifs à vos tables de données. Le nom se trouve dans l’application Power Apps lorsque vous écrivez le code pour vous y connecter.
  • Utilisez une table de données par feuille de calcul.
  • Donnez le même nom à la table de données et à la feuille de calcul.
  • Utilisez des noms de colonne descriptifs dans les tables de données.
  • Utilisez la casse Pascal. Chaque mot du nom Table de données doit commencer par une lettre majuscule, telle que EmployeeLeaveRequests.

Noms de variable

Les conventions de dénomination des variables dans les applications canevas sont importantes pour maintenir la lisibilité, la cohérence et la clarté de vos projets Power Apps. Bien qu’aucune norme stricte ne soit appliquée, l’adoption d’une convention d’affectation de noms cohérente dans votre application canevas peut vous permettre, ainsi qu’à d’autres collaborateurs, de comprendre, d’utiliser et de gérer plus facilement les variables.

  • Utilisez la notation camelCase, où la première lettre de chaque mot est en majuscule, à l’exception du premier mot.
  • Choisissez des noms significatifs et descriptifs qui décrivent clairement l’objectif ou le contenu de la variable. Évitez les noms trop génériques comme temp ou var1. Utilisez plutôt des noms descriptifs comme userEmail ou totalAmount.
  • Pensez à utiliser des préfixes ou des suffixes pour indiquer le type de variable. Par exemple :
    • strUserName pour une variable de texte/chaîne
    • numTotalAmount pour une variable numérique
    • boolIsEnabled pour une variable booléenne
    • locVarName pour les variables locales/variables de contexte
    • gblVarLoginUser pour les variables globales
  • Décidez si vos variables doivent être nommées à la forme singulière ou plurielle et respectez cette convention. Par exemple, utilisez userCount systématiquement ou users.
  • Évitez d’utiliser des mots ou noms réservés qui pourraient entrer en conflit avec des fonctions ou mots-clés Power Apps. Consultez la documentation Power Apps pour obtenir une liste de mots réservés.
  • Pensez à utiliser des préfixes qui fournissent un contexte sur l’utilisation ou la portée de la variable. Par exemple :
    • frm pour les variables de formulaire
    • col pour les collections
    • var pour les variables à usage général
  • Évitez les caractères spéciaux. Maintenez les noms alphanumériques et évitez les caractères spéciaux ou les espaces. Limitez-vous aux lettres et nombres.

Power Apps permet aux variables de contexte et aux variables globales de partager les mêmes noms. Ce partage peut entraîner une confusion, car vos formules utilisent des variables de contexte par défaut, sauf si vous utilisez l’opérateur d’ambiguïté.

Évitez cette situation en suivant ces conventions :

  • Ajoutez le préfixe loc aux variables de contexte.
  • Ajoutez le préfixe gbl aux variables globales.
  • Le nom après le préfixe doit indiquer l’intention ou l’objectif de la variable. Vous pouvez utiliser plusieurs mots sans avoir à les séparer par des caractères spéciaux, tels que des traits de soulignement, si vous mettez en majuscule la première lettre de chaque mot.
  • Utilisez la casse chameau. Commencez vos noms de variable par un préfixe en lettres minuscules, puis mettez en majuscule la première lettre de chaque mot du nom.

Ces exemples suivent les normes et les conventions :

  • Variable globale : gblFocusedBorderColor
  • Variable de contexte : locSuccessMessage
  • Variable d’étendue : scpRadius

Ces exemples ne respectent pas les normes et sont plus difficiles à comprendre :

  • dSub
  • rstFlds
  • hideNxtBtn
  • ttlOppCt
  • cFV
  • cQId

Évitez les noms de variables courtes et cryptiques comme EID. Utilisez EmployeeId à la place.

Lorsqu’une application a de nombreuses variables, tapez le préfixe dans la barre de formule pour afficher la liste des variables disponibles. Si vous suivez ces instructions pour nommer vos variables, vous pouvez les trouver facilement dans la barre de formule lorsque vous développez votre application. En fin de compte, cette approche conduit à un développement d’applications plus rapide et plus efficace.

Noms de collection

  • Utilisez des noms qui décrivent le contenu de la collection. Réfléchissez à ce que contient la collection et comment elle est utilisée et nommez-la en conséquence.
  • Ajoutez le préfixe col aux noms de collection.
  • Utilisez le nom après le préfixe pour afficher l’intention ou l’objectif de la collection. Vous pouvez utiliser plusieurs mots sans espaces ou traits de soulignement si vous mettez en majuscule la première lettre de chaque mot.
  • Utilisez la casse chameau. Démarrez vos noms de collection avec un préfixe minuscule col , puis mettez en majuscule la première lettre de chaque mot dans le nom.

Ces exemples suivent les conventions pou les noms de collection :

  • colMenuItems
  • colThriveApps

Ces exemples ne suivent pas les conventions pour les noms de collection :

  • orderscoll
  • tempCollection

Astuce

Lorsqu’une application a de nombreuses collections, tapez le préfixe dans la barre de formule pour afficher la liste des collections disponibles. Si vous suivez ces instructions pour nommer vos collections, vous pouvez facilement les trouver dans la barre de formule lorsque vous développez votre application. Cette approche entraîne un développement d’applications plus rapide.

Commentaires et documentation

Lorsque vous écrivez du code pour votre application, concentrez-vous sur l’ajout de commentaires clairs. Les commentaires vous aident à comprendre le code plus tard et facilitent le travail du développeur suivant sur le projet.

Power Apps prend en charge deux styles de commentaires pour rendre votre code plus clair : les commentaires de ligne, qui utilisent des barres obliques doubles (//) pour les notes sur une seule ligne, et les commentaires de bloc, qui utilisent /* et */ pour les notes sur plusieurs lignes.

Commentaires de ligne

Ajoutez une double barre oblique (//) à n’importe quelle ligne de code dans Power Apps pour convertir le reste de la ligne en commentaire.

Utilisez les commentaires de ligne pour expliquer ce que fait la ligne de code suivante. Vous pouvez également les utiliser pour désactiver temporairement une ligne de code à des fins de test.

Voici un exemple de commentaire de ligne.

// ClearCollect function populates the Expenses2 collection with sample data
ClearCollect(
    Expenses2,
    // Entry 1: Client hosted meet and greet
    {
        Title: "Client hosted meet and greet:",
        ID: "4"
        // additional properties  
    }
)

Commentaires en bloc

Le texte entre /* et */ est un commentaire de bloc. Les commentaires de bloc peuvent couvrir plusieurs lignes, contrairement aux commentaires de ligne, qui ne couvrent qu’une seule ligne.

Utilisez les commentaires de bloc pour des explications plus longues, comme la documentation d’un en-tête de module de code. Vous pouvez également les utiliser pour désactiver temporairement plusieurs lignes de code pendant les tests ou le débogage.

Pour une meilleure organisation du code, ajoutez des commentaires après avoir utilisé la fonctionnalité de mise en forme du texte. Cette approche permet de faire apparaître vos commentaires avant un bloc de code.

/*
    Patch Operation to Insert Data:
    - Inserts a new employee record into the 'Employee' entity.
    - Adds corresponding department details to the 'Department' entity.
    Note: Ensure that foreign key relationships and dependencies are maintained for data integrity.
*/
Patch(
    Employee,
    Defaults(Employee),
    {
        FirstName: "John",
        LastName: "Doe",
        Position: "Software Developer"
    }
)

La fonctionnalité de mise en forme du texte suit les règles suivantes pour les commentaires :

  1. Si une propriété commence par un commentaire de bloc, la ligne de code suivante lui est ajoutée.
  2. Si une propriété commence par un commentaire de ligne, la ligne de code suivante n’y est pas ajoutée. Sinon, le code est mis en commentaire.
  3. Les commentaires de ligne et de bloc situés ailleurs dans la propriété sont ajoutés à la ligne de code qui précède.

Ne vous inquiétez pas d'ajouter trop de commentaires ou des commentaires trop longs. Power Apps supprime tous les commentaires lorsqu’il crée le package d’application cliente. Les commentaires n’affectent pas la taille du package, la vitesse de téléchargement de l’application ou les heures de chargement.

Concepteur d’applications moderne avec commentaires

Dans Power Apps, utilisez les fonctionnalités de commentaire dans Power Apps Studio et le concepteur d’applications moderne.

Pour ajouter des commentaires dans Power Apps Studio, utilisez ces méthodes :

  • Cliquez avec le bouton droit sur les points de suspension (« ... ») d’un élément dans la vue en arborescence.
  • Cliquez avec le bouton droit sur un composant dans la zone du canevas.
  • Sélectionnez le bouton Commentaires situé dans la barre de commandes en haut à droite de l’écran.

Lorsque vous mentionnez un collègue dans un commentaire, utilisez le symbole « @ » suivi de son nom. Cette action envoie un e-mail de notification à la personne que vous balisez. Si l’utilisateur indiqué n’a pas accès à l’application, Power Apps vous invite à partager l’application avec lui.

Capture d’écran d’une application expenses montrant une personne mentionnée avec @ dans un commentaire.

Mise en retrait et mise en forme

L'indentation et le formatage aident à maintenir votre application claire et organisée. Lorsque votre code est bien mis en forme, il est plus facile de lire et de comprendre.

Mise en retrait

Power Apps n’applique pas de mise en retrait stricte. Utilisez des espaces pour séparer différentes sections de vos formules. Appuyez plusieurs fois sur la barre d’espace pour créer une mise en retrait.

Sauts de ligne

Divisez les formules longues en plusieurs lignes pour les rendre plus faciles à lire. Appuyez sur Entrée pour ajouter un saut de ligne dans la barre des formules.

Utiliser la commande Formater le texte

La commande Mettre en forme le texte dans la barre de formule ajoute des retraits, de l’espacement et des sauts de ligne à votre code Power Apps. Utilisez la commande Format de texte pour conserver un style de codage cohérent dans votre application canevas et pour éviter les erreurs.

Capture d’écran de Power Apps Studio avec la commande Format de texte mise en surbrillance.

Étape suivante