Power Apps Canvas App Coding Standards: Naming Conventions
The Power Apps Canvas App Coding Standards whitepaper was introduced by Microsoft back in 2018 to document best practices for coding canvas apps. A collaborative effort by Microsoft and members of the Power Apps community, it is among my favorite pieces of writing on Power Apps and I have put nearly all of its lessons into practice over the years.
I’ve decided to write my own take on the coding standards for two reasons. First, I want to share where my opinions differ on canvas apps development and my reasons for them. Second, despite good intentions the canvas app standards never became the ‘living document’ it was intended to be. We’ve not had an update to the standards since their initial publication.
These are my own opinions on naming conventions in Power Apps canvas apps for screens, controls, variables, collections and data sources.
Table Of Contents: Screen Names Control Names Variable Names Collection Names Datasource Names
A screen name should describe its purpose in 1-2 words suffixed by the word ‘Screen’. Use proper-case.
It is important that each screen’s purpose is described in plain-language because screen-readers will speak this text to visually-impaired users when the screen loads. If the screen has more than one-purpose, consider distributing the functionality across multiple screens.
- Appointments Screen
- Order Form Screen
- Collect Signature Screen
- Appointments [missing the word ‘Screen’]
- OrderFormScreen [not friendly to a screen reader]
A control name should indicate the control-type, which screen is found on and its purpose. Use camel-case separated each piece of information with an underscore. This example shows a text input, found on the Order Form Screen whose purpose is to capture the first name of the person placing the order.
When typing a formula in the editor we often want to reference another control. We don’t often remember the control’s name and rely on auto-complete to find it. First we write the control type to narrow the list of possible matches and then we type the screen name to refine the search further. The result is a list of all controls on the screen with a matching type.
The full list of control name abbreviations can be found below:
|Rich Text Editor||rte|
- drpNewEmployeeDepartment (no spacing)
- btn_Submit_OrderForm (wrong order)
- gly_Home_Appointments (control abbreviation not found in standard list)
A variable name should show the scope of the variable, the data type and its purpose. Use camel-case with no spaces between each word. This example is a global variable which holds the current user’s email address.
The scope of a variable restricts where it can be used in the app – every screen in the app (global), one specific screen (local) or within a specific code-block (function). A prefix indicating the variable’s scope helps us quickly understand where it is available.
Variables can only hold a single, consistent data-type throughout the app. If a variable is set as a text data type in one code block and set as a number data type elsewhere the app will show an error the next time its opened in studio mode. This type of error can be incredibly frustrating to track down in a large app. For this reason it is important to know what data type a variable holds.
- gblUserCurrent (no data type)
- Loc_BlockUserInput (improper capitalization and spacing)
- WorkdaysBetween (no scope or data type)
A collection name should communicate the original datasource of the table and its purpose. Use camel-case with no spaces between each word.
Collection data can be generated from one of two places – a persistent table from a connected datasource or a temporary table created inside the app. Persistent tables must have data periodically read/written back to them. Understanding where the data originally came from makes this task easier.
|None (created in-app)||(none)|
- colEmployees (missing datasource)
- NavigationMenu (missing prefix)
A datasource name should describe its purpose. There is no word limit but keep it short. Use proper-case.
In many cases a developer has no choice over the datasource name and must use what is already in place. There may also be constraints imposed by the datasource itself. Whenever possible be as concise and clear about the purpose of the datasource as possible.
- Construction Projects
- Repair Orders
- Emp (abbreviation instead of full word)
- Projects (too general, what type of projects)
- RepairOrders (no spacing, hard to read)
Did You Enjoy This Article? 😺
Subscribe to get new Power Apps articles sent to your inbox each week for FREE
If you have any questions or feedback about Power Apps Canvas App Coding Standards: Naming Conventions please leave a message in the comments section below. You can post using your email address and are not required to create an account to join the discussion.