Following the release of the Microsoft PowerApps Canvas App Coding Standards and Guidelines document couple of weeks ago, I am going in a series of articles to cover different aspects of building stable and performant PowerApps Applications.

Coding Standards and Guidelines

In today’s article, I will cover the naming conventions for controls in PowerApps.

PowerApps Controls Naming Conventions

As the majority of programming languages have a preferred naming convention (for controls, variables …etc.), whether you want to use “camel case” or “Pascal case”, it is really up to you.

I have to highlight that there is nothing wrong with naming your controls label1, label2 if you are building apps for learning only. However, good luck with large business applications, with hundred of controls.

Camel Case

Following the Camel Case, your controls and variables will begin with a lowercase prefix, followed by a capital letter for each word (after the first).

txtSelectUserDropDown

Pascal Case or Upper Camel Case

Similar to the Camel case except that all the first letters of the control or variable will be in upper case.

TxtSearchUser

Naming Conventions

As you build your app with multiple screens, controls and data sources, it is important to follow a certain naming convention and make sure these are consistent across all your app.

1. Screens Names

Ideally the screens names should tell clearly the purpose of each screen.

Very important ! for accessibility needs, especially for the vision accessibility needs, you need to remember that the screen names are read aloud by screen readers, so be sure the name is self explanatory.

It is recommended to include the word “screen” in the screen names, for example:

1.1 Good screens names:

Home Screen
Products Screen
Help Screen

1.2 Bad screens names:

Dashboard
RequestDetails
ListOfProductsScreen

2. Controls Names

Ideally, controls’ names should use the camel case and follow the following format:

• three letters describing the type (txt, btn, crd, img, lbl …etc)
• Followed by the purpose of the control.

2.1 Good controls names:

lblUserName
txtSearchQuery
imgLogo
btnSubmitForm

2.2 Bad controls names:

label_search_query
TextEnterYourEmail
Image_Logo_192x192
ButtonSumit1

2.3 Abbreviations for controls:

Button –> btn
Canvas –> can
Card –> crd
Collection –> col
Dates –> dte
Combo Box –> cmb
Drop Down –> drp
Form –> frm
Gallery –> gal
Group –> grp
Icon –> ico
Image –> img
Label –> lbl
Shape –> shp
Table –> tbl
Text Input –> txt
Timer –> tim

3. Variables scopes

We have to be careful with the variables used in the app. Certain variables have a global scope in your app, which might lead to some sort of confusion if not names properly.

Any variable you define with the Set function has an app wide scope.

In contrary, Context variables live in the screen where they are declared from.

Global Variable : gblMyVariable

Context Variables : locTotalValue