Power Apps- Naming Conventions

I'm pretty certain you have already read an article on naming conventions, so let me first say sorry. With everyone often forgetting its subjective, personal preference and no one right answer. And now let me explain why mine is the best 🤥

Mostly the focus for naming conventions is navigation and code sharing, my focus includes them, but is predominately about speed of development.

Intellisense is a developers best friend, and we should be leveraging our naming conventions to empower it more.

The approach should try and use a version of progressive filtering, which means every character we type should exponentially decrease the options for intellisense.

In progressive filtering as the search term is edited the list or results is updated.

There are also 3 fundamental rules to all naming:

1. It must be clearly descriptive of what it is/does.
2. Camelcase is king.
3. Avoid spaces.

---

So let's start from the top:

Solutions

Often this is forgotten about, but its very important, as established environments can end up a long list of solutions, with the only way to see the detail is to open them.

Geo-Dept-Project

Geo - although most environments are geo specific, geos can be more granular e.g Environment Europe, geo Denmark, or they can be helpful if different geos have shared development environment.

Dept and Project are quite obvious, as they allow easily clarification, validation for ALM and a good link to any documentation.

Additionally any flows that are part of the solution should have same naming structure (this really helps when all flows are listed in my flows).

Geo-Dept-Project-FlowName

The App name can be anything you like, as this is user facing it should not follow any naming conventions, except that it should follow standard marketing principle of being memorable and related to its functionality.

Screens & Containers

Now here I'm probably different to most, I don't think screen or containers need a naming convention. This is because of 2 reasons:

1. There shouldn't be too many of them.
2. They aren't referenced. (I know screens are referenced with navigation but that's a very limited use case)

And this goes back to my speed approach, screens and containers won't appear in intellisense when trying to reference anything.

So as long as our screen and containers follow the fundamental rules, we don't need to worry about anything else.

NB The additional of _ref can be used, see components to understand how and why.

Variables & Collections,

Variables, collections and components, are where naming conventions are key. As they are not only the most reference, they will be the highest volume and be most difficult to find.

Variables

scopetypeName
e.g vsUserName

Scope - this is either global or local, so a good practice would actually be g an l. And this is where anti-patterns appear, anti-patterns are contradictory rules that still have a logic. So for me, who has a background in JavaScript, my muscle memory is for var and let, so I have v for global and l for local.

Now if I had no muscle memory I would actually choose y for global and z for local (crazy I know), but the reason is intellisense. If I used y and z, then my first character typed would instantly remove all incorrect scope variables, and all components (you will see why in component naming section).

This is personally less of an issue for me because I very rarely use local variables (bad habit I know), and the odds of me using multiple video components is close to zero (vi is used for video).

Type - this is important for 2 reasons, ensuring you don't set them incorrectly, and again for speed, as we can then decrease our variable options massively by the type.

They are all pretty self explanatory, except object. Object kind of covers everything else, so it could be row of data, rgb colour, icon, screen, etc. You can split these out if you want, but in my experience in apps these are kept to a minimum so once I get to vo my list of intellisense is already at a good length.

Descriptive Name - This just needs to follow the fundamental rules to help make it readable and memorable (so when typing you can remember it).

Here I also have another strange anti-pattern, vis. When I first started development I would label all variables that controlled visibility as vis, they were all global and I wanted to identify these specific booleans. I'm trying my hardest to drop this anti-pattern, as vbworks well and a good proportion of booleans are generally used for visibility.

*Collections - * as these are all global they don't need a type, so I use col, it allows me to distinguish them from variables and has good muscle memory. The reason is not co is for the clash with comboBoxes.

coMyArrayOfData

Components

In most apps this will be the biggest section to reference, as all components are global we don't follow the variable pattern, and as there are more, a single letter isn't enough.

typeName_Ref
e.g laName

Type - when referencing a component we know the type, so that should be our first filter. I work along first 2 letters, Button= bu, Label= la, etc. It's great for muscle memory as no need to learn it, just start typing what it is.

Descriptive Name - This just needs to follow the fundamental rules to help make it readable and memorable.

Ref - This is an optional addition, and is used to reference a screen or container. So if you had to duplicate a screen instead, you can use _Ref to link the components to the parent screen or container. A top tip for this is to user numbers, as when you copy and paste, Power Apps adds _1/_2 to the end of the containers and/or component's automatically.

containerName_1
laName_1
laAddress_1
laTelephone_1

That way you save time on lots of renaming.

Custom Components
Custom components should follow similar structure, with the first 2 characters 'cu', and descriptive name, but before the ref you should add a abbreviation for the library (if applic). So something like this:

cuMenubarCorp_1

Where Corp is the library and Menubar is the descriptive name.

---

Let me give you an example of why I like my naming conventions, we start with 50 options:

vsUser,vsUser2,vsUnifrom,vsWhen,vsOption1,vsOption2,lsOption1,lsOption2,lsUnifrom,viTimer,viTimer2,viCounter,viID,viRef,liID,liRef,vbOption1Visible,vbOption2Visible,voColour,voDownArrow,laName,laAddress,laTelephone,laLastName,laWelcome,laTitle,laSubTitle,laDescription,laCost,laNext,laPrevious,buCancel,buSubmit,buChange,buUpdate,buEnd,buExit,buHelp,buPrevious,buBack,imLogo,icDownArrow,viGuide,htTable,drPostCodes,coUsers,peSign,inName,inAge,inAddress

first character v, now we have 16:

vsUser,vsUser2,vsUnifrom,vsWhen,vsOption1,vsOption2,viTimer,viTimer2,viCounter,viID,viRef,vbOption1Visible,vbOption2Visible,voColour,voDownArrow,viGuide

second character s, now we have 6:

vsUser,vsUser2,vsUnifrom,vsWhen,vsOption1,vsOption2

third char U

vsUser,vsUser2,vsUnifrom:

As you can see, after typing 3 characters I have only 3 options left, this is great if I can't remember the full name. And for speed one more character and I could have my variable selected.

---

As I said, naming conventions are personal and subjective (everyone has their own muscle memory and anti-patterns), it's great if a company has rules all developers follow, but at the same time a good naming convention should be logical enough anyone can pick it up quickly.

---

For some other naming conventions ideas check out:
matthewdevaney.com
powerusers.microsoft.com
learn.microsoft