Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Namenskonventionen
Namenskonventionen – Allgemeines
In diesem Abschnitt werden die Namenskonventionen „Camel Case“ und „Pascal Case“ beschrieben. Wenn Sie mit diesen Begriffen bereits vertraut sind, können Sie diese Abschnitte überspringen.
Camelcase
Sie sollten für Steuerelemente und Variablen Camel Case verwenden. Camel Case beginnt mit einem Kleinbuchstabenpräfix, entfernt alle Leerzeichen aus Objekt- oder Variablennamen und schreibt den ersten Buchstaben jedes Worts nach dem ersten groß. Ein Texteingabesteuerelement könnte beispielsweise txtUserEmailAddress heißen.
Pascal-Case
Sie sollten für Datenquellen die Pascal-Schreibweise verwenden. Der Pascal-Case wird manchmal auch als „Upper Camel Case“ bezeichnet. Wie bei Camel Case werden alle Leerzeichen entfernt und der erste Buchstabe des Wortes wird groß geschrieben. Im Unterschied zum Camel Case wird beim Pascal Case jedoch auch das erste Wort groß geschrieben. Eine gängige Datenquelle in PowerApps ist beispielsweise der Microsoft Office 365-Benutzende-Connector, der in Ihrem Code „Office365Users“ heißt.
Bildschirmnamen
Bildschirmnamen sollten den Zweck des Bildschirms widerspiegeln, um Navigation durch komplexe Apps in Power Apps Studio zu erleichtern.
Weniger offensichtlich ist, dass Bildschirmnamen von Bildschirmleseprogrammen vorgelesen werden, die für Benutzer mit sehbehindertengerechter Bedienung erforderlich sind. Daher ist es zwingend erforderlich, dass Sie für die Benennung Ihrer Bildschirme eine einfache Sprache verwenden und dass die Namen Leerzeichen und keine Abkürzungen enthalten. Außerdem empfehlen wir, den Namen mit dem Wort „Bildschirm“ zu beenden, sodass der Kontext, wenn der Name ausgesprochen wird, verstanden wird.
Hier sehen Sie einige gute Beispiele:
Home_Screen
oderHome Screen
Search_Screen
oderSearch Screen
Diese Beispielbildschirmnamen sind weniger verständlich:
Home
LoaderScreen
EmpProfDetails
Thrive Help
Steuerelementnamen
Alle Steuerelementnamen auf der Leinwand sollten Camel Case verwenden. Sie sollten mit einem dreistelligen Deskriptor beginnen, gefolgt vom Zweck des Steuerelements. Dieser Ansatz hilft dabei, den Steuerungstyp zu identifizieren und erleichtert das Erstellen von Formeln und die Suche. Beispielsweise gibt lblUserName
an, dass es sich bei dem Steuerelement um eine Beschriftung handelt.
In der folgenden Tabelle sind die Abkürzungen für gängige Steuerelemente aufgeführt.
Steuerelementname | Abkürzung |
---|---|
Badge | bdg |
Button | btn |
Kamera-Steuerelement | cam |
Canvas | can |
Card | crd |
Diagramme | chr |
CheckBox | chk |
Sammlung | col |
Combo box | cmb |
Komponente | cmp |
Container | con |
Datumsangaben | dte |
Dropdown | drp |
Form | frm |
Galerie | gal |
Gruppieren | GRP |
Header | hdr |
HTML-Text | htm |
Schaltfläche | ico |
Image | img |
Info-Schaltfläche | -Info |
Label | lbl |
Verknüpfung | lnk |
Listenfeld | lst |
Mikrofon | mic |
Microsoft Stream | str |
Form des Seitenabschnitts | s |
Stifteingabe | pen |
Power BI-Kachel | pbi |
Statusanzeige | pbar |
Rating | rtg |
Rich-Text-Editor | rte |
Formen (Rechteck, Kreis usw.) | shp |
Schieberegler | sld |
Registerkartenliste | tbl |
Table | tbl |
Texteingabe | Txt |
Selbstauslöser | tmr |
Umschaltfläche | tgl |
Video | vid |
Eine detaillierte Liste der Steuerelemente und ihrer Eigenschaften finden Sie in der Steuerelementereferenz.
Hinweis
Steuerelementnamen müssen innerhalb einer Anwendung eindeutig sein. Wenn ein Steuerelement auf mehreren Bildschirmen wiederverwendet wird, sollte der kurze Bildschirmname ein Suffix haben. Beispiel: galBottomNavMenuHS
, wobei „HS“ für „Home Screen“ (Startbildschirm) steht. Dieser Ansatz erleichtert die Referenzierung des Steuerelements in Formeln über mehrere Bildschirme hinweg.
Hier sehen Sie einige schlechte Beispiele:
zipcode
Next
Wenn Sie Ihre Steuerelemente konsistent benennen, ist Ihre App in der Navigationsansicht übersichtlicher und auch Ihr Code ist übersichtlicher.
Datenquellennamen
Wenn Sie Ihrer Anwendung eine Datenquelle hinzufügen, kann der Name in der Power Apps-App nicht geändert werden. Der Name wird vom Quellkonnektor oder den Datenentitäten übernommen, die aus der Verbindung abgeleitet werden.
Hier sehen Sie einige Beispiele:
- Vom Quellconnector geerbter Name: Der Office 365-Benutzende-Konntektor heißt in Ihrem Code Office365Users.
- Aus der Verbindung abgeleitete Datenentitäten: Eine Microsoft- SharePoint Liste mit dem Namen
Employees
wird vom SharePoint Connector zurückgegeben. Daher lautet der Name der Datenquelle in Ihrem Code „Employees“. Dieselbe Power Apps App kann auch denselben SharePoint Connector verwenden, um auf eine SharePoint Liste mit dem NamenContractors
zuzugreifen. In diesem Fall lautet der Name der Datenquelle im CodeContractors
.
Weitere Informationen zu Connectors und Verbindungen finden Sie in der Übersicht über Canvas-App-Connectors für Power Apps.
Standardaktions-Connectors
In Standard-Aktionskonnektoren, die Funktionen verfügbar machen, wie z. B. LinkedIn, wird für den Datenquellennamen und seine Vorgänge die Pascal-Schreibweise verwendet. Beispielsweise heißt die LinkedIn-Datenquelle LinkedIn und verfügt über eine Operation namens ListCompanies
.
ClearCollect(
colCompanies,
LinkedIn.ListCompanies()
)
Benutzerdefinierte Konnektoren
Benutzerdefinierte Connectors zum Herstellen einer Verbindung mit benutzerdefinierten Anwendungsprogrammierschnittstellen (APIs), wie z. B. Diensten oder branchenspezifischen APIs, die Ihr Unternehmen erstellt hat. Sie können von jedem Erstellenden in Ihrer Umgebung erstellt werden. Wir empfehlen die Pascal-Schreibweise für den Datenquellennamen und seine Operationen. Beachten Sie jedoch, dass sich der Name des benutzerdefinierten Connectors und seine Darstellung in PowerApps unterscheiden können.
Betrachten Sie dieses Beispiel eines benutzerdefinierten Konnektors mit dem Namen MS Auction Item Bid API
.
Wenn Sie jedoch von diesem Connector aus eine Verbindung erstellen und ihn Ihrer PowerApps-App als Datenquelle hinzufügen, erscheint er als AuctionItemBidAPI
.
Um den Grund herauszufinden, können Sie in der OpenAPI-Datei nach einem Titelattribut suchen, das den Text Auction Item Bid API
enthält.
"info": {
"version": "v1",
"title": "Auction Item Bid API"
},
Power Apps entfernt alle Leerzeichen aus diesem Attributwert und verwendet ihn als Namen Ihrer Datenquelle.
Tipp
Wir empfehlen, den Wert dieses Attributs in einen Namen mit Pascal-Case AuctionItemBidAPI
zu ändern und ihn als Namen Ihrer benutzerdefinierten Verbindung zu verwenden. Auf diese Weise kommt es zu keiner Verwirrung. Ändern Sie diesen Wert, bevor Sie die OpenAPI Datei importieren, um den benutzerdefinierten Connector zu erstellen.
Hinweis
Wenn Sie die Option Von Grund auf neu erstellen verwenden, statt eine vorhandene OpenAPI Datei zu importieren, PowerApps werden Sie aufgefordert, den benutzerdefinierten Connector-Namen einzugeben. Dieser Name wird sowohl als Name des benutzerdefinierten Connectors als auch als Wert des Titelattributs in der Datei OpenAPI verwendet. Achten Sie darauf, einen Namen in Pascal-Schreibweise wie AuctionItemBidAPI
zu verwenden, um die Konsistenz und Einfachheit zu wahren.
Excel-Datentabellen
PowerApps verwendet DataTables in Microsoft Excel, um eine Verbindung zu Daten in Excel-Arbeitsblättern herzustellen. Beachten Sie diese Punkte, wenn Sie Excel-Dokumente als Datenquellen erstellen:
- Geben Sie Ihren DataTables aussagekräftige Namen. Der Name steht in der Power Apps App, wenn Sie den Code zum Herstellen einer Verbindung damit schreiben.
- Verwenden Sie eine DataTable pro Arbeitsblatt.
- Geben Sie der DataTable und dem Arbeitsblatt den gleichen Namen.
- Verwenden Sie in den DataTables aussagekräftige Spaltennamen.
- Verwenden Sie die Pascal-Schreibweise. Jedes Wort des DataTable-Namens sollte mit einem Großbuchstaben beginnen, z. B.:
EmployeeLeaveRequests
Untypisierte und dynamische Objekte
Variablennamen
Namenskonventionen für Variablen in Canvas-Apps sind für die Lesbarkeit, Konsistenz und Klarheit Ihrer Power Apps-Projekte wichtig. Obwohl kein strenger Standard durchgesetzt wird, können Sie und Ihre Mitarbeitenden Variablen mithilfe der Einführung einer einheitlichen Namenskonvention für Ihre Canvas-App eventuell leichter verstehen, verwenden und verwalten.
- Verwenden Sie Camel Case, wobei der erste Buchstabe jedes Wortes mit Ausnahme des ersten Wortes groß geschrieben wird.
- Wählen Sie aussagekräftige und beschreibende Namen, die den Zweck oder Inhalt der Variable klar beschreiben. Vermeiden Sie zu allgemeine Namen wie temp oder var1. Verwenden Sie stattdessen beschreibende Namen wie „userEmail“ oder „totalAmount“.
- Erwägen Sie die Verwendung von Präfixen oder Suffixen, um den Variablentyp anzugeben. Beispielsweise:
strUserName
für eine Text-/ZeichenfolgenvariablenumTotalAmount
für eine numerische VariableboolIsEnabled
für eine boolesche VariablelocVarName
für lokale Variablen/KontextvariablengblVarLoginUser
für globale Variablen
- Entscheiden Sie, ob Ihre Variablen im Singular oder Plural benannt werden sollen, und halten Sie sich an diese Konvention. Verwenden Sie beispielsweise durchgängig „userCount“ oder „users“.
- Vermeiden Sie die Verwendung von reservierten Wörtern oder Namen, die mit Power Apps Funktionen oder Schlüsselwörtern in Konflikt geraten könnten. Eine Liste der reservierten Wörter finden Sie in der Power Apps Dokumentation.
- Erwägen Sie die Verwendung von Präfixen, die Kontext zur Verwendung oder zum Umfang der Variablen bieten. Zum Beispiel:
frm
für Formularvariablencol
für Sammlungenvar
für Allzweckvariablen
- Verwenden Sie keine Sonderzeichen. Achten Sie auf alphanumerische Namen und vermeiden Sie Sonderzeichen oder Leerzeichen. Verwenden Sie nur Buchstaben und Zahlen.
Power Apps erlaubt, dass Kontext- und globale Variablen sich den gleichen Namen teilen. Dies kann zu Verwirrung führen, da Ihre Formeln standardmäßig Kontextvariablen verwenden, sofern nicht der Begriffsklärungsoperator verwendet wird.
Vermeiden Sie diese Situation, indem Sie die folgenden Konventionen befolgen:
- Stellen Sie Kontextvariablen
loc
voran. - Stellen Sie globalen Variablen
gbl
voran. - Der Name nach dem Präfix sollte die Absicht/den Zweck der Variable angeben. Es können mehrere Wörter verwendet werden und sie müssen nicht durch Sonderzeichen wie Leerzeichen oder Unterstriche getrennt werden, sofern der erste Buchstabe jedes Wortes groß geschrieben ist.
- Verwenden Sie Camel-Case-Schreibweisen. Beginnen Sie Ihre Variablennamen mit einem Präfix in Kleinbuchstaben und schreiben Sie dann den ersten Buchstaben jedes Wortes im Namen groß.
Diese Beispiele folgen Standards und Konventionen:
Globale Variable:
gblFocusedBorderColor
Kontextvariable:
locSuccessMessage
Umfangsvariable:
scpRadius
Diese Beispiele entsprechen nicht den Standards und sind schwieriger zu verstehen:
dSub
rstFlds
hideNxtBtn
ttlOppCt
cFV
cQId
Vermeiden Sie kurze und kryptische Variablennamen wie EID. Nehmen Sie stattdessen Use EmployeeId
.
Wenn eine App viele Variablen enthält, können Sie einfach das Präfix in die Formelzeile eingeben, um eine Liste der verfügbaren Variablen anzuzeigen. Wenn Sie sich an diese Richtlinien zum Benennen Ihrer Variablen halten, können Sie sie beim Entwickeln Ihrer App problemlos in der Formelzeile finden. Letztendlich führt dieser Ansatz zu einer schnelleren App-Entwicklung.
Sammlungsnamen
- Beschreiben Sie den Inhalt der Sammlung. Überlegen Sie, was die Sammlung enthält und/oder wie sie verwendet wird, und benennen Sie sie entsprechend.
- Sammlungen sollte
col
vorangestellt werden. - Der Name nach dem Präfix sollte die Absicht oder den Zweck der Sammlung angeben. Es können mehrere Wörter verwendet werden, die auch nicht unbedingt durch Leerzeichen oder Unterstriche getrennt werden müssen, sofern der erste Buchstabe jedes Wortes groß geschrieben wird.
- Verwenden Sie Camel-Case-Schreibweisen. Beginnen Sie Ihre Sammlungsnamen mit dem Präfix „col“ in Kleinbuchstaben und schreiben Sie dann den ersten Buchstaben jedes Wortes im Namen groß.
Die folgenden Beispiele folgen den Konventionen für Sammlungsnamen:
colMenuItems
colThriveApps
Die folgenden Beispiele folgen nicht den Konventionen für Sammlungsnamen:
orderscoll
tempCollection
Tipp
Wenn die App viele Sammlungen enthält, können Sie einfach das Präfix in die Formelleiste eingeben, um eine Liste der verfügbaren Sammlungen anzuzeigen. Wenn Sie sich beim Benennen Ihrer Sammlungen genau wie bei Variablen an diese Richtlinien halten, können Sie sie beim Entwickeln Ihrer App völlig problemlos in der Formelzeile finden. Letztendlich führt dieser Ansatz zu einer schnelleren App-Entwicklung.
Kommentare und Dokumentation
Betonen Sie beim Schreiben des Codes für Ihre Anwendung die Bedeutung umfassender Kommentare. Diese Kommentare dienen nicht nur als hilfreiche Anleitung, wenn Sie die Anwendung Monate später erneut aufrufen, sondern sind auch ein Ausdruck der Dankbarkeit gegenüber dem nächsten Entwickler, der an dem Projekt mitarbeitet.
Es gibt zwei Haupttypen von Kommentaren zur Verbesserung der Verständlichkeit von Code: Power Apps unterstützt zwei Kommentarstile: Zeilenkommentare, bei denen es sich um einzeilige Kommentare handelt und die durch doppelte Schrägstriche (//
) gekennzeichnet werden, und Blockkommentare, bei denen es um mehrzeilige Kommentare handelt und die innerhalb von /*
und */
umrahmt werden.
Zeilenkommentare
Das Hinzufügen eines doppelten Schrägstrichs (//
) zu einer beliebigen Codezeile in PowerApps kennzeichnet den Rest der Zeile (einschließlich //
) als Kommentar.
Nutzen Sie Zeilenkommentare, um die Funktionalität des nachfolgenden Codes zu erläutern. Sie können auch dazu dienen, eine Codezeile vorübergehend zu deaktivieren, was sie für Testzwecke nützlich macht.
Dieses Beispiel zeigt die Verwendung von Zeilenkommentaren.
// 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
}
)
Blockkommentare
In /*
und */
eingeschlossener Text wird als Blockkommentar erkannt. Im Gegensatz zu Zeilenkommentaren, die sich auf eine einzelne Zeile beziehen, können Blockkommentare sich über mehrere Zeilen erstrecken.
Blockkommentare sind nützlich für mehrzeilige Erklärungen, wie etwa die Dokumentation einer Codemodulüberschrift. Sie ermöglichen außerdem das vorübergehende Deaktivieren mehrerer Codezeilen während des Testens oder Debuggens.
Für eine optimale Codeorganisation empfiehlt es sich, nach der Verwendung des Features „Text formatieren“ Kommentare hinzuzufügen. Dies ist von Vorteil, wenn Ihre Kommentare einem Codeblock vorangehen.
/*
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"
}
)
Das Feature „Text formatieren“ befolgt diese Regeln für vorhandene Kommentare:
- Wenn eine Eigenschaft mit einem Blockkommentar beginnt, wird die nächste Codezeile daran angehängt.
- Wenn eine Eigenschaft mit einem Zeilenkommentar beginnt, wird die nächste Codezeile nicht daran angehängt. Andernfalls wird der Code auskommentiert.
- Zeilen- und Blockkommentare an anderen Stellen der Eigenschaft werden an die vorherige Codezeile angehängt.
Machen Sie sich keine Sorgen, wenn Sie zu viele oder zu lange Kommentare hinzufügen. Wenn PowerApps das Client-App-Paket erstellt, werden alle Kommentare entfernt. Daher haben sie keinen Einfluss auf die Paketgröße und verlangsamen nicht die Download- oder Ladezeiten der App.
Moderner App-Designer mit Kommentaren
In Power Apps gilt es für Erstellende als bewährte Methode, das Kommentarfeature sowohl in Power Apps Studio als auch im modernen App Designer effektiv zu nutzen.
Für eine optimale Beteiligung an Power Apps Studio sollten die Erstellenden Kommentare mithilfe der folgenden Methoden hinzufügen:
- Klicken Sie mit der rechten Maustaste auf die Auslassungspunkte („...“) eines beliebigen Elements in der Strukturansicht.
- Klicken Sie mit der rechten Maustaste auf eine Komponente im Canvas-Bereich.
- Wählen Sie die Schaltfläche „Kommentare“ in der Befehlsleiste in der oberen rechten Ecke des Bildschirms.
Beim Erwähnen von Kollegen in Kommentaren wird empfohlen, das Symbol „@“ gefolgt von ihrem Namen zu verwenden. Dadurch wird eine Benachrichtigungs-E-Mail an den markierten Kollegen gesendet, um einen schnellen Zugriff auf den Kommentar sicherzustellen. In Fällen, in denen ein markierter Benutzer keinen Zugriff auf die App hat, wird der Hersteller aufgefordert, die App mit ihm zu teilen.
Einrückung und Formatierung
In Power Apps sind Einrückungen und Formatierungen von entscheidender Bedeutung, um in Ihrer App eine klare und übersichtliche Struktur beizubehalten. Durch Befolgen bewährter Methoden verbessern Sie die Lesbarkeit Ihrer Formeln und Steuerelemente.
Bearbeitungsleiste
Einrücken
Obwohl Power Apps keine strikte Einrückung erzwingt, können Sie Leerzeichen verwenden, um verschiedene Abschnitte Ihrer Formeln optisch zu trennen. Drücken Sie die Leertaste mehrmals, um einen Einrückungseffekt zu erzeugen.
Zeilenumbrüche
Sie können lange Formeln zur Verbesserung der Lesbarkeit auf mehrere Zeilen aufteilen. Drücken Sie die Eingabetaste, um einen Zeilenumbruch innerhalb der Formelleiste einzufügen.
Verwenden Sie den Befehl „Text formatieren“
Der Befehl „Text formatieren“ in der Formelleiste dient dazu, Einrückungen, Abstände und Zeilenumbrüche auf Ihren Power Apps-Code anzuwenden. Nutzen Sie den Befehl „Text formatieren“, um einen einheitlichen Codierungsstil für Ihre gesamte Canvas-App festzulegen und so einen effizienteren und fehlerresistenteren Entwicklungsprozess sicherzustellen.