Power Apps Naming Conventions For Canvas Apps

It is important to have a consistent set of naming conventions for all of the objects in a Power Apps canvas app. By following the same patterns all Power Apps developers can more quickly understand each others apps and introduce less bugs when working on them. 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

Screen Names

A screen name should describe its purpose in 1-2 words suffixed by the word ‘Screen’. Use proper-case.

Home Screen

Discussion

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.

Good Examples

• Appointments Screen
• Order Form Screen
• Collect Signature Screen

Bad Examples

• Appointments [missing the word ‘Screen’]
• OrderFormScreen [not friendly to a screen reader]

Control Names

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.

txt_OrderForm_FirstName

Discussion

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:

Good Examples

• drp_NewEmployee_Department
• btn_OrderForm_Submit
• gal_Home_Appointments

Bad Examples

• drpNewEmployeeDepartment (no spacing)
• btn_Submit_OrderForm (wrong order)
• gly_Home_Appointments (control abbreviation not found in standard list)
  

Variable Names

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.

gblTextUserEmailCurrent

Discussion

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.

Good Examples

• gblRecordUserCurrent
• locBoolBlockUserInput
• varNumWorkdaysBetween
  

Bad Examples

• gblUserCurrent (no data type)
• Loc_BlockUserInput (improper capitalization and spacing)
• WorkdaysBetween (no scope or data type)

Collection Names

A collection name should communicate the original datasource of the table and its purpose. Use camel-case with no spaces between each word.

colDvInvoices

Discussion

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.

Good Examples

• colSpEmployees
• colDvSalesLeads
• colNavigationMenu

Bad Examples

• colEmployees (missing datasource)
• NavigationMenu (missing prefix)

Datasource Names

A datasource name should describe its purpose. There is no word limit but keep it short. Use proper-case.

Sales Leads

Discussion

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.

Good Examples

• Employees
• Construction Projects
• Repair Orders
  

Bad Examples

• Emp (abbreviation instead of full word)
• Projects (too general, what type of projects)
• RepairOrders (no spacing, hard to read)

Questions?

If you have any questions or feedback about Power Apps Canvas Naming Conventions For Canvas Apps 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.