#1 – Naming Conventions & Cases
Cases
Camel case – should be used for controls and variables – begins with a lowercase prefix, and each following word has the first letter capitalised e.g. gblColourTheme
Pascal case – should be used for data sources – includes no spaces, and all words have the first letter capitalised e.g. MyDataverseTable
Naming Screens – Key Accessibility Tip
You should always make sure that your screen names are in plain english and generally finish with ‘Screen’. This is so they are readable by screen readers where people use this tool to support an accessibility need
Naming Controls
Controls use camel case and should begin with a three letter descriptor followed by the control use e.g. btnSubmitRequest
You can also find further naming conventions guidance in the above whitepaper.
Naming Variables
Variables use camel case and should be named differently depending on the type of variable we’re using.
If we’re declaring a global variable, we should use the prefix abbreviation gbl.
If we’re declaring a local variable, we should use the prefix abbreviation loc.
Global variable example – gblCurrentUser
Local variable example – locSelectedRecord
#2 – App OnStart Property
The OnStart property is a great tool for you to use to run one-time needed formulas to start up your app.
A number of things may be included in an app OnStart, such as:
✅ Defining a theme
✅ Defining and setting default values for global variables
✅ Creating data collections
Keep in mind the more we pack into this property, the longer our application may take to load.
#3 – Limit control amounts
It’s important that we make attempts to reduce the number of controls we’re adding to our application for a number of reasons:
✅ Having less controls is easier to control and organise when it comes to renaming our controls and understanding what we have in our application
✅ Reducing the number of controls in our applications means faster load times
But, what can we do to reduce the number of controls? Here’s some tips…
✅ Consider multiple application based solutions where we don’t try to pack everything into one application if it becomes too big
✅ Set variables for things like form modes to prevent creating multiple forms for viewing and editing a selected record.
✅ Set variables for things like selected records so one form can be used for multiple galleries that look at the same data source.
#4 – Tooltips
Adding tooltips to your controls is such an important coding standard, especially with a focus on accessibility. Let’s say you have a visually impaired user accessing your application, and they need to select an icon to run a process in your app. They need to be able to have a screen reader read out the tooltip on that icon to understand what it does. Without this, they’d be unable to use your application.
#5 – Version Notes
Version notes are something we can add each time we publish a version of our application. Version notes allow us to describe the changes we have made to a version of our application, allowing for other developers to see what we have changed.
A good example of how version notes could be useful is when we have a problem or bug in our application. We’d easily be able to go back through our version notes and restore the version of our application that would fix the bug, whilst understanding the potential features we’re about to remove.
#6 – Code Comments
By adding a double forwards slash (//) we can add line comments in Power Apps, and by adding /* and */ we can add a block comment which will comment out multiple lines.
It’s really important that we add comments to our code to describe what it does. This not only makes it easier for us to understand when we come to make updates to our application in the future, but it also makes life a lot easier for another developer if they ever take on the development of our application in the future.
#7 – Documentation screens
An additional screen that you can only see in the edit mode of your application is a great way to document the various collections, variables and naming conventions we’ve adopted in our application. This makes it much easier for future developers to take on the development of our applications.
#8 – Run testing
This might be a slight lean away from a coding standard and might be more of a development practice, but running testing is essential in the development of a Canvas app. By running testing we reduce the chance of issues when we deploy our application to production. We can further reduce this risk by conducting User Acceptance Testing.
#9 – If() or Switch()
One of the things we can do to make our apps more efficient is understand when to use different syntax in our formulas.
Whilst we could use an If() statement like this for a fill property:
If(ThisItem.Column.Value = “Value1”, Red, ThisItem.Column.Value = “Value2”, Green, ThisItem.Column.Value = “Value3”,Blue,White)
It is much better to use a Switch() statement like this:
Switch(ThisItem.Column.Value, “Value1”, Red, “Value2”, Green, “Value 3”, Blue, White)
#10 – Minimal Data Sources
It’s important that we don’t include too many data sources in our application. If we add 30 SharePoint lists for example, it will take ages to load our application if all of these have lots of records.
By reducing the number of data sources we have in our application we will make load times much faster resulting in a better user experience.
I hope you found this post useful. If you have any other coding standards you implement in your applications, please comment them below!
Subscribe
Sign up with your email address to receive news and updates.
Thank you for subscribing!