cancel
Showing results for 
Search instead for 
Did you mean: 

A PowerApps Naming Convention Proposal

A PowerApps Naming Convention Proposal

 

What’s in a name?  Well, if you take the amount of effort that some brands go to in order to make themselves immediately recognisable, it would appear that names are rather important. 

One of the things that has become apparent to me over the last 6 or so months as I have built my own apps, both at work and at home, is that having a strong and consistent naming convention is immensely useful to me.  Additionally, having benefitted from being able to see the apps that other people produce, both by using products that people have loaded onto the PowerApps bank, and also by watching videos produced by a wide range of professionals it is apparent that there are a very wide range of naming conventions already in use.

In this article I’m going to explore why names are important, and make a proposal as to how we might choose to name our objects in the future.

Are Names Important?

Object names exist throughout PowerApps ranging from text boxes, dropdowns, buttons, variables and so on.  They are unavoidable in any PowerApps solution, however simple.  Here are some reasons why names are important:-

Maintenance

Have any of you inherited an excel spreadsheet produced by someone other than yourself?  If you have then you’ll know how disorientating it is to try and fathom out the intentions of the creator.  The apps that we produce to help run our businesses cannot be made in a way that makes them difficult to maintain or support.  A strong, sensible, consistent naming convention will help with this.

Scalability and Efficiency

If you are producing apps at scale across your organisation there are patterns of behaviour that you may wish to reproduce over and over again.  If you’ve created names that are so bespoke as to only ever relate to a specific app then this becomes much more difficult.

Development Efficiency

Linked in with maintenance the search function works like a dream when you have a good naming convention and allows developers to navigate around the app more easily.  Below is a figure showing this in action.

 

PASearch.JPG

Community Development

If as a community we are to create great solutions I believe that this will be on the back of creating really great reproduceable patterns of behaviour.  However, if we don’t maintain a consistent manner of describing our objects our formulas will be less readable and less transferrable. As a result our collective rate of progress will be limited somewhat.

Is it easy?

It’s relatively easy to name objects in a consistent fashion, the difficulty is to get everybody in the community to do the same thing.

A Naming Convention Proposal

Ok let’s get serious. I’m going to offer a proposal for a naming convention and request that you all use the comments section below to see if it's agreeable to us all.

The proposal is as follows:-

Object

Category

Proposal

Alternatives

Timer

Controls

tmrXXXX - Where XXXX is bespoke to your application

 

Audio file

Controls

audXXXX

 

Check Box

Controls

chkbxXXXX

check 

Button

Controls

btnXXXX

 button

Combo Box

Controls

cmbXXXX

combo 

Date Picker

Controls

datepkXXXX

 

Radio

Controls

radioXXXX

 

Slider

Controls

sliderXXXX

sldr 

Rating

Controls

ratingXXXX

 

Import

Controls

importXXXX

imp 

Export

Controls

exportXXXX

exp 

Power BI Tile

Controls

pbiXXXX

 

Attachments

Controls

attXXXX

 

Collection

Data Sources

cnXXXX

 

Data Entry Form

Forms

frmXXXX. Where the there is only one data entry form frmInput is preferred. 

 

Data Entry Card (the card that holds all the objects for a given field)

Forms

cardFieldName(where FieldName is the system name for the field)

e.g. cardDateCreated

 

Datacard Value (the specific input that pushes data into the dataset)

Forms

dcvFieldName e.g. dcvDateCreated

 

Gallery

Gallery

glryXXXX

 

icon

Icons

icnXXXX

icon 

Image

Media

imgXXXX

 

Camera

Media

camXXXX

 

Barcode

Media

barcXXXX

brc 

Video

Media

vidXXXX

 

Microphone

Media

micXXXX

 

Add Picture Button

Media

addpicXXXX

 

Screen

Screen

scrnXXXX where XXXX is your choice

 

Opening screen

Screen

scrnLandingXXX

Alternative is scrnHome. ScrnLanding is preferred as the home screen may not be the same as a landing screen as this may just be a once only welcome.

Label

Text Objects

lblXXXX

 

Text Input box

Text Objects

txtinpXXXX

 

Pen Input

Text Objects

peninpXXXX

 

HTMLText

Text Objects

lblhtmlXXXX

 

Rich Text Editor

Text Objects

lblrichXXXX

 

Global Variable

Variables

gvXXXX

 

 To see it in operation, take a look at the video below, If you are feeling keen download the standalone app from the PowerApps Bank here and review it on your own tenant.:-

That doesn’t sound too difficult.  Is there a catch?

I wouldn’t say that there is a catch, but I would say that you may choose to leave your legacy apps alone, unless of course you are using one as a template for all other forms.  If that is the case I think that it is worth the effort to go through a renaming exercise.  Provided that you are methodical, and correct any issues as you go it is not a huge problem.  If you do work with global variables, you must make sure that they are corrected everywhere they are used, and this is best done by interrogating using the file->variables->Global variables->definitions route and correcting it in every place.  You will also need to correct it every place it is used by looking under ‘uses’.

Collections are quite a bit more difficult to rename as there is no means at this stage to verify where they are being used in the app (so good luck with that!).

I think I’ll stay as I am

Deciding to stay as you are is effectively a decision to accept whatever defaults are offered by PowerApps to you.  In the simple example of creating 4 buttons you will end up with 4 objects called Button1, Button2, Button3 and Button4, but you won't have any idea as to what they do.

 

ButtonsNaming.JPG

 

As your apps become more complex it is highly likely that you and your team will suffer the consequences at some point in the future.  Troubleshooting an app with a naming convention, writing formulas and even seeing all your objects through search facility and the left hand side pane are significantly easier with a naming convention over the out of the box names.  The figure below shows the search function in operation.  With the exception of variables, every object with "bomb" in the name is easily identified.

MinesweeperSearch.JPG

I have no problem at all with the existence of default names, as these are designed to help new users to the platform, but as we push on our approach to developing apps as a community a shared way of working will be most beneficial.  Try it – you might like it!

Comments below

We’re just at the start of a PowerApps revolution, and I think if you’ve landed here, you probably already know this.  The specific naming convention chosen isn’t as important as simply having one and sticking to it, but if we all have the same one, then we will all be able to run much, much faster.  Take a look at the example Minesweeper app by downloading it here and review it on your own tenant.

By all means provide comments on the proposal shown above, and suggest your own alternatives as maybe I’ve overlooked something along the way.

 

Comments

Hi, my preference is generally for 3 digit prefixes if possible.

 

Visual Basic mostly uses 3 digit prefixes for controls, see:

 

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/aa263493(v=vs.60)

 

in particular for me:

Checkbox: chk (no need for the bx)

DatePicker: dtp

Radio: rdo

etc.

 

just a thought!

Thanks tchagan - this is brilliant feedback - just what I was after.  I'm quite tempted to see about creating a microsoft form and running a little survey to see if we can gain some collective consistency.  I do like the idea of 3 digits, I guess you'd have to run through all the possibilities to see if they make sense. Smiley Happy

Hi @rorybi,

 

Very good subject! A good naming convention is indeed important and I also hear people structure with it.

 

He is my naming convention:

  1. Identifier for the control type
    1. I use short identifiers where possible (dd, cb, lbl, ti, btn, icn, gall,  ...)
  2. Identifier for the screen
  3. Identifier for the control / identifier for a panel / identifier for a gallery (gall)
    1. A panel is a subsection on a screen.
  4. Identifier for the control
    1. Unless this was also the case for (3).
  5. More detail
    1. I do not like ending with a number. I always try to give more detail when similar controls exists.

I use underscores to separate sections.

 

Example:

lbl_Home_Panel1_Week_Start
dd_Home_Panel1_Week_Start

This is for a dropdown on the home screen containing weeks when using panels (it is on the first panel in this case). The dropdown has a label above it. 

 

Robot Happy Rick

Rory,

 

I totally agree with this and frankly have been doing it since day one.  For those not doing it I can promise you that things are much easier when you can absolutely understand the notion of what you are dealing with right up front as you write and troubleshoot code.

 

One particular naming pattern I am starting to adopt to assist other in understanding my code is to delineate a collection, a record and a table so I prefix with col, rec and tbl.  For PowerApps it is really key to understand the differences and using a naming convention goes a long way to helping developers think through what they are doing.

 

Excelent initiative, one addition: if possible limit prefixes to 3 character. Important to have a consistent approach so not slider but sld. Based on the idea to consequently skip vowels until you have 3 characters. Of course the prefix should be unique.

Downside to this rigorous approach is that sometimes you end up with diffucult to read prefixes, then it time to make an exception Smiley Happy

 

In the old Visual Basic / VBA times this was a proven way to make your code easier to maintain.

Hi All,

Thanks for all your comments.  It seems like the 3 digit prefix is preferred and I think I will update the convention accordingly. 

@Rick72 it would be really helpful to see your approach in action as it would make for relatively long control names and therefore formulas that might be on the long side.  Nevertheless, I suspect if you had a really massive app this would be a great help.

 

Hi @rorybi,

 

I have added a screenshot below. As you can see, I keep the screen identifiers short because the names become indeed long then. I also have a documentation screen explaining which screen is used for what.

 

Robot Happy Rick

 

2018-11-03_D.PNG

Thanks @Rick72 - you've probably gone for a Platinum level naming convention and I suspect if your methodology is followed through it would be very easy in the end.  I'm at this stage just trying to move us on to start with the 3 digit prefix (as opposed to the wild west of naming).  I'd still be a little wary of the length of the names in the formulas, but maybe it's a price worth paying for having a convention where you can find what you're looking for.  Thanks so much for sharing.

Hi @rorybi ,

 

I like the idea of naming standards, however there is one thing that we need to consider here.

 

As documented the accessibility checker flags up default Screen names.  

 

The important part of this document is the following:

 

Revise screen name Tip When a screen has a default name, which will be read out by screen readers when users navigate the app. Give the screen a name that describes what's on the screen or what it's used for. People who are blind, have low vision, or a reading disability rely on screen names to navigate using the screen reader.

 

screen reader read out the screen name. Hence I would suggest that the screen are called something like "Home Screen" or "Dashboard Screen" or maybe even just "Home" or "Dashboard" rather than something with a prefix and without spaces.

Hi @Pieter_Veenstra - I totally agree.  Actually, at the time of writing the article I wasn't fully au fait with how that would work from an accessibility point of view, but you are quite right.