by A while ago, I wrote an article about SharePoint best practices, and I think it’s a good time to start one for Power Apps. Like in my SharePoint article, a few disclaimers first.
Everything contained in this article is my personal opinion, so feel free to disagree and adapt any of them to your needs.
The point is not to have a standard that everyone will use, but for you to think and implement one that makes sense to your reality. I will improve it over time, so feel free to contact me and propose topics that are missing. Finally, this article can change over time since I’ll learn new stuff over time, so feel free to interact on Twitter or send me an email with suggestions, or come back once in a while because there may be something new. Will all these disclaimers out of the way, let’s get started.
Variables
Variables exist in every programming language that you can remember, so Power Apps are not the exception. Not that I’m saying that Power Apps is a programming language per se, and, although it’s in the family of “Low Code” applications, there are places here and there where you can include formulas and some minor code.
Best Practices
Variables in Power Apps should follow the same rules as in every programming language. They need to be:
- Descriptive. You should be able to understand by looking at the name; what’s it’s purpose.
- Unique. You should be able to identify your application.
- Don’t have the same name as other structures in the system. For example, you should not call your variable “max” because it’s a function name.
Recommendations
There’s more, but these are the most important. But let me add a few tips:
- Never sacrifice the length of the variable in place of understanding what it does. For example, “maxPax” we can understand it’s the maximum people, but of what? There’s no context. “Pax” can also not be apparent for everyone. Why not call the variable “maxNumberOfPeopleInvited.” It’s a bit longer, but it reads quite clearly. It’s the max number of people invited. Much more context than the previous case.
- Don’t start with numbers or special characters. Some programming languages support them (Swift even supports emoji for the names of the variables), but that’s not a reason you should do it. Variables should represent entities, and rarely you’ll need to define it with a number.
- Use “camelCase” when naming them. Again, some people prefer to use underscores, but the camel case makes things, in my option, much more cleaner. Besides, most languages use the camel case as the “recommended” strategy, so it’s good to go with the majority in this case.
- Singular form for unique values, for example, a “Text” value. Use the pluralized version if the variable contains a list of items. Then you’ll know by looking at the variable that it has one or more values.
- Lower case always. Use upper case for collections and data sources.
- Don’t use any prefix to identify if it’s a local or global variable (Microsoft recommends this). Keep things simple and, if the variable is descriptive enough, you don’t need any prefix.
Please note that you can name your variables anything you want, but if you’re going to show your “code” to other people or collaborate on an app, it’s essential to have a common understanding of what things mean. Otherwise, you’ll be introducing bugs or taking a lot longer to understand what the app is doing.
Controls
If you build a Power App, you’ll probably use hundreds of controls. They are the building blocks of your whole application, but since you’re using them a lot, following some rules is imperative so that you don’t get lost in your app.
Abbreviations
It’s common practice to use abbreviations to understand what’s the control purpose. For example, you can name your controller “imgLogo” if you want to represent an image of the logo of your company. Microsoft recommends using them and has a list of accepted abbreviations. I’m not going to list them here, but if you want, please check the best practices document, and you’ll find them.
I can’t say I agree with the usage of abbreviations. I don’t like to introduce steps where people have to learn the language so that they can understand something. Languages are complex enough so let’s not make them more complicated. Like I mentioned before, don’t sacrifice the length of the variable in place of understanding what it does, and this is perfect. There’s no shame in having big variable names as long as they prevent people from having to check what “can” means, for example (it’s “canvas” by the way). Please call it “canvas” and remove unnecessary entropy.
Best Practices
They should follow the same structure as variables. In my opinion, they are entirely analogous, although they serve different purposes.
Screens
Screens are where you use your controls. They contain a lot of them, but each application is expected not to have many screens.
Recommendations
In this case, I agree with Microsoft when recommending that they are descriptive, using plain language and spaces. Some examples can be “Main Screen,” “Login Screen,” or “Personal Information Screen.”
The only thing that I leave up to you is to add “Screen” at the end of the name. Personally, it’s obvious it’s a screen, but if you want to make it extra descriptive, I have nothing against it. But don’t:
- Use abbreviations
- Camel or Pascal case
- Start with the word “Screen.”
Use always the first word to group screens based on their functionality. Since Power Apps sorts them alphabetically, it’s an excellent way to have everything nice and organized.
Data Sources
Almost all Power Apps use Data Sources to store and retrieve information to display the user. There are hundreds of potential data sources, but all of them inherit the name from the source. For example, if you’re using a SharePoint data source and connecting to a “Person” list, then the data source will be called “Person.” It’s imperative that the source also follows the rules in naming their objects. In SharePoint’s case, I wrote an article so that you can “just” import the data sources, and all of them will have the names correctly formatted.
Best Practices
We touched in the variables section, but they should:
- Name them based on Pascal Case and always in the plural form. All of them contain multiple records, so you know that you’re using a list of something.
- I know there’s the temptation to use prefix or suffix to identify that it’s a data source. Don’t do it. As long as it’s uppercase, you know it’s a data source.
- Power Apps will remove spaces, but if there are some underscores, remove them also, unless they are essential to understand the data source’s objective.
Collections
Microsoft describes collections as “a group of items that are similar, such as products in a product list.” So if this is the case, treat them as data sources and use the same strategies, recommendations, and naming conventions. They are different objects, but they serve the same objective. Microsoft recommends using the “col” prefix in each. Don’t do it. Make your name descriptive that is a collection, but it’s a lot nicer to have “SubsetOfPeopleToImport” than “colPeopleToImport.” Prefixes make things complicated and, again, forces you to know what each means. Don’t use them.
Final Thoughts
The article only scratches the surface on all the topics that we can cover in Power Apps. Notice that we only covered the main entities and didn’t cover organization, performance improvements, functions’ rules (for this, I’ll do it in my own Power Apps Reference). I’ll probably write part 2 and 3 of this article or continue building on this one to have a full reference. I don’t know yet, but I wanted to start with something and evolve it as time passes.
Finally, Microsoft has an excellent guide for Power Apps Canvas Apps Coding Standards and Guidelines. Please note that some of my recommendations go against some of the rules in this document. Please read both of them and make your own decision about what works better in your organization.
Have a suggestion of your own, or disagree with something I said? Leave a comment or interact on Twitter and be sure to check out other Microsoft Power Apps-related articles here.
Photo by Aziz Acharki on Unsplash
