1995 was a long time ago. But I still vaguely remember the BASIC Programming Language class that I took (more like, pretended to take) while also playing a game called Alley Cat on a black-and-white screen. Every class and institute back then would teach the same way – using plain letters as variables, e.g. a, b, c or abc, pqr, etc. It was easier to get by with such simple variables back then, but in today’s world of complex and advanced tools like UiPath, coding best practices are more important than ever.
*Ahem* Let’s come back to the future!
Over the years, as programming languages have become more advanced to execute much more complex algorithms, collaborating on big projects has become a necessity as well. And like any other team effort, it became essential to have a common set of rules for programmers – let’s call it pro-code! But since no one asked me for my wordplay skills back then, today this set of rules is commonly known as Coding Best Practices. (Sometimes also called Coding Standards and Best Practices)
What are coding best practices used in UiPath?
Since Robotic Process Automation is an art form where you need to learn the collaboration dance, these coding practices are as relevant to RPA as any other vanilla programming language. If you use UiPath Studio, you may have been a victim (or a culprit) of variables that make no sense and make you question everything!
Beginner or professional, any programmer’s worst nightmare is unreadable variable names! Single letters or letter sequences are a really bad choice for naming variables. However, when using logical names for variables, it’s also important to separate the words well so that they are easily readable. That’s just a very basic guideline for variable management.
I have five easy and simple variable naming hacks that will instantly improve your code readability and slow down your receding hairline at least a bit.
So, let’s get started!
Note: This article has some screenshots that are specific to UiPath Studio. However, the concepts discussed here are broadly applicable to any programming language. Please drop a comment below to ask or suggest clarifications on any topic you feel is important. 🙂
1. Use CamelCase
This is one of the most fundamental concepts for any programmer and it does wonders to make a code snippet readable.
What is CamelCase?
CamelCase is a commonly followed naming convention in several programming languages, in which we declare longer variable names that are more relevant to the process and/or the piece of code where we are using it. If a variable name has multiple words in it – which is ideal in most cases – the first letters of each word can be capitalised to make the variable readable.
Take a look at these example variables below. In the first one – MyFirstUnicorn – I am capitalising the letters M, F and Uā¦ which makes it easy for me to read despite it being one word. (At the risk of stating the obvious, variable names cannot contain spaces and a few other special characters)
Underscores are underrated!
Some people also use underscores in variable names and it’s got its own merits, too. It’s as much a personal preference as it is its own technique. But there are good arguments for using the underscore character to separate words, especially in cases where abbreviations are involved.
e.g. My_RPA_Variable is much more readable than myRPAVariable.Takeaway
Whether to use camelCase or underscores, the choice is yours. But they are both better choices than using letter sequences for your variables or using multiple words without separation.
Come up with a convention – for yourself or within your team – and follow it.
2. Maintain Case Sensitivity In Variables
This is kinda obvious after reading the first one. If you’re using CamelCase or a combination of uppercase and lowercase characters in a variable name, it would help to keep the case consistent whenever that variable is called.
However, in .NET (the language that runs and supports UiPath) and also within UiPath Studio, Case Sensitivity isn’t strictly expected. In other words, you could declare your variable with a particular sequence of upper and lower case characters, but ignore the case when calling the variable somewhere else.
The compiler won’t complain because it reads and treats them the same. The same cannot be said about your teammate. In the interest of keeping code quality and the team’s sanity high, it is recommended that you use the variables just as they are in the original declaration.
And, the easiest way to do that is to use the keyboard shortcut CTRL + SPACE which brings up a list of all the variables available to you and choose the one you need.
CTRL + SPACE to see available variables at any time3. DON’T Use Keywords or Class Names
The concept of keywords and class names deserves its own article. But to help emphasise this point, here is a quick refresher.
Keywords: Every programming language has a set of predefined, reserved set of words that have a special meaning to the compiler (the thing that converts our program into 1’s and 0’s for the computer to understand).
For example, a programming language that has the keyword
IFto add conditional logic may not allowIFto be used as a variable name.Class: A class is a definite structure in a programming language which has some properties and functions that help create a reusbale identity or object.
For example, class
Studentmay have properties likeName,RollNumberand functions such asSkipLectures,PullAllNightersandPretendToBeAwake.
Can I use keywords or class names as variable names?
Consider a standard class from the DOT NET Framework, say FileInfo.
If you want to load a local file into the program to perform some File I/O (Input/Output) operations, the FileInfo class can give you programmatic access to its important attributes, such as where is the file located, whether the file exists and a few other important details.
However, if I name my variable fileinfo which is also the name of a class in DOT NET, the compiler may allow it in some cases. It does reserve some keywords and class names from being used as variable names. An example is shown below for the frequently used variable type String. Notice that UiPath Studio doesn’t present a similar error for fileinfo (first variable in the list)
But, should I use keywords or class names as variable names?
Although the UiPath Studio variable manager generally accepts most class names as variable names, it is likely to cause confusion when you’re building or maintaining the code. There may be situations where even the Studio compiler will not compute or cause an issue that will be difficult to debug if you’re not careful.
For instance, let’s say you want to check the absolute path of a file (Absolute Path is the complete address of a fail – all the way from the Drive name, e.g. “C:\Program Files\...\filename.txt“). This can be achieved using a standard class System.IO.Path by calling its method GetFulPath(filename).
Look at the “Message” part in the Log Message activity below.
Time to confuse the compiler…
Now, let’s add a variable to the sequence and see the effect on the existing code.
Now, don’t get me wrong, expert programmers will quickly point out the problem here and also know how to fix it. But, that’s precisely my point. Everyone who shares or works on your code – whether concurrently or in future – may not be an expert programmer. Knowing which keywords or class names to avoid in variables is a surefire way to ensure there’s no confusion!
Psst… in case you’re wondering how to avoid the method suggestion confusion…
You just need to provide the absolute class name and method to inform Studio what class you’re referring to.
See the image below. Instead of using the relative method call (Path.<>) I have used the absolute call (System.IO.Path.<>) which brings up the correct method suggestions I want.
4. Use Datatype Prefixes
Let’s describe a real use case. I am building a robot to download historical stock market data on a daily basis. There is a list of stocks for which to download the data from a finance website. Here is my optimised workflow to dynamically download data per search term.
A quick look at the variables panel shows the ease of use achieved by simply naming variables starting with a common string, usually denoting their data type. This creates a visual separation of variables which is also easy to remember.
Do I really need to use prefixes for variable names?
Now, UiPath Studio is a visual tool. So you can easily sort your variable names by their datatype. In this screenshot the sort order is alphabetical. However, by using a simple prefix you can have an instant recall even when using the variables in the program. Instead of having to double-check the variables panel frequently, you can simply bring up variable suggestions of certain data types by typing the prefix.
Personally, I use these prefixes:
strfor myStringvariablesdtfor myDataTablevariablesintforIntegervariablesarrforArrayvariableslistforList<T>variables (where<T>is any type of object, e.g.List<String>for a list of Strings)
No more conflicts!
As far as UiPath coding best practices are concerned, the beauty of this system is that you can customise it to however you want. If you work in a team, you can spend 15-30 minutes coming up with a commonly agreeable naming convention.
5: Arguments need coding best practices too!
Arguments are slightly different to variable names. One wouldn’t use them directly within a sequence or a workflow. Instead, we pass them into another workflow when using Invoke Workflow File activity.
Which Types Of Directions Can An Argument Have In UiPath Studio?
Arguments can have any data type just like any variable, but they have an additional property called direction. This direction of an argument dictates when and where its value can be assigned or changed. You can set an argument’s direction property to one of three values as described below.
IN– An argument having this direction may only receive a value from outside. The compiler won’t return the updated value to the calling workflow.OUT– An argument having this direction can only send a value out from this workflow. You cannot set an initial or default value. The workflow can update and return the new value to the calling workflow.IN/OUT– An argument having this direction can both receive a value and return an updated value to the calling workflow. We use this when modifying an existing object while using a reusable workflow code.
If you read UiPath’s official documentation page for managing arguments, you will see a different description. (Also, there is a fourth direction named Property. But it’s currently not in use and hence not important right now.)
I read the UiPath docs page and thought it could have some more information. So, I have explained it this way. You are welcome to read both. Let me know in the comments if this helps. 😉
How Do You Write Arguments In UiPath?
You can create arguments in the Arguments Panel of UiPath Studio. It is the same as creating variables and you may name your arguments in any way you prefer. However, coming back to the coding best practices, everything I said about variables also applies to arguments. The four strategies discussed in this article can be used in the Arguments panel too.
If you look back at the UiPath docs page referenced above, there is a hyperlink to another page about Automation Best Practices. You will find quoted below, the only important guideline relating to naming your arguments.
Argument names should have a prefix stating the argument type, such as
Reference: UiPath Docs ā Automation Best Practices ā Workflow Design ā Naming Conventions sectionin_DefaultTimeout,in_FileName,out_TextResult,io_RetryNumber.
How do you pass a variable from one sequence to another in UiPath?
Take a look at the workflow that we invoked in the example from #4. Use Datatype Prefixes. Notice that the variables used in that example correspond to the arguments used here, with the addition of direction prefixes to the argument names. This approach makes it really easy to maintain consistency and avoid confusion.
I have added a screenshot of the “Invoke Workflow” call used within the project.
As seen above, it is recommended to name your arguments starting with prefixes that indicate the direction (io_ refers to IN/OUT). This makes argument management significantly easy because you don’t need to double-check the direction when using an argument.
However, if you’re not careful, there is a potential pitfall waiting to happen even though you follow the above guideline.
An Additional Coding Best Practice for Arguments in UiPath
When you create an argument in UiPath, by default its direction is IN. Regardless of whether you name your argument starting with the recommended prefix (in_ / out_ / io_) or without any prefix, the direction is set automatically to IN.
If you forget to change the direction corresponding to what you expect from an argument, the argument may not yield the result you want and may become more difficult to debug.
Several UiPath developers – including yours truly – have made this mistake before!
Take your arguments seriously. I know the pain of going through your Arguments panel umpteen times only to realise too late that the argument named out_Result is actually has the direction IN.
That is why I urge you: Argue Responsibly! (err… I mean, name your arguments responsibly.)
Now, I showed you mine…
There is also a video on this topic I published a while ago and would love to hear your thoughts on it!
These are my five tips that will hopefully help you build better robots and write more readable code. If you have ONE takeaway from this article, let it be that the easiest coding best practices are those that you can remember without making any extra effort. I hope this article gives you ideas to work within your team and come up with your own variable management system which you shouldn’t have to memorise!
Share you own coding best practices in UiPath (or otherwise)!
What are some coding standards and strategies that you follow religiously? Drop them in the comments! Look forward to learning from you.
You may be wondering why I wrote a heavily technical article focused entirely on UiPath. This article should help explain why I think UiPath is an excellent tool for any starter (and advanced) RPA developer.
Also, you may not find BASIC language that appealing, but you can always have fun playing Alley Cat! 🐈
I’ll talk to you in my next post. Until then, Happy Automation!
