Coding standards are a collection of rules, guidelines, and best practices. Coding standards are important for safety, security, and reliability. In this course, we learn the most important and UiPath recommended coding standards. Starting from naming conventions to maintaining your code in the code repository, we cover all the best practices.
Meaningful names should be assigned to workflow files, activities, arguments, and variables in order to accurately describe their usage throughout the project.
Firstly, projects should have meaningful descriptions, as they are also displayed in the Orchestrator user interface. Moreover, adopting a good naming strategy for environments, assets, and queues makes the management of the virtual workforce in Orchestrator more manageable.
Only argument names are case sensitive, but to improve readability, variables and the other entities should also align to the same naming convention.
- Variables should be upper Camel Case, e.g. FirstName, LastName.
- Arguments should be in upper Camel Case with a prefix stating the argument type, e.g. in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.
- Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep the part of the title that describes the action (Click, Type Into, Element exists, etc).
Except for Main, all workflow names should contain the verb describing what the workflow does, e.g. GetTransactionData, ProcessTransation, TakeScreenshot
- Use one variable for one and only one purpose.
- Minimize the scope of each variable.
- Keep statements that work with the same variable(s) as close together as possible.
- Variables will always have meaningful names. The variable name should fully and accurately describe the entity the variable represents. State in words what the variable represents.
- We will use the upper Camel Case (Pascal case) for naming variables. This practice used compound words, no other characters between the words, where each word will start with a capital letter. Ex: TransactionNumber, FilePath, ReportName, etc.
- The length of the variable name should be between 6 and 20 characters long. If you feel that 20 characters are not enough, consider abbreviating longer words. Shorter variables names can be used when using a local scope (like index, file, row).
- Datatable object: Start with dt_ prefix followed by the normal name. Ex: dt_Employees, dt_Reports.
- Boolean type: Give Boolean variables names that imply True or False. You can use the prefix is followed by the name. Ex. ApplicationExists, isRed, isFound, etc. Always use positive names, negatives names (Ex: notFound) should be avoided if possible.
Same guidelines as for variables, with the below differences:
- Each argument will have a prefix depending on the direction: in, out, io followed by the underscore character (“_”). Example: in_Config, out_InvoiceNumber, io_RetryNumber, in_dt_Employees.
- Use default values for arguments either for testing individual workflow files, or, in case of reusable components, for using default configuration. When invoking a workflow file, UiPath allows the flexibility to pass a value to any of the defined arguments, having essentially all possible signatures defined by the argument list. This allows for using the default value of an argument for which no value is passed upon invoking the file. Specify what is the default configuration in the description of the reusable workflow file.
Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep the part of the title that describe the action (Click, Type Into, Element exists etc). In case an activity throws an exception the source of the exception will contain the activity name, so a proper name to each activity is advisable for an easy understanding of the exception. Take extra care in renaming activities that have a standard name, like Assign, If, For each or Sequence for which the name doesn’t automatically change – one would need to manually rename them.
- Upper Camel Case naming.
- A workflow file starts with the prefix containing Application Name. E.g. for working in SAP: SAP_Login.xaml, or SAP_ExtractClientReport. Typically, workflow files belonging to the same application or system will be grouped together in one folder under the project root folder. In case there are many files for one application, further categorizing by using subfolders can be used.
- When using a template framework – the framework files come already created and are standard (including Main.xaml) – they should not be changed.
- When using a test framework – for the Test_Framework files – Use the prefix Test_ for a workflow file that runs tests. Place these files in the Test_Framework folder.
- For an easier understanding, use number prefixes to emphasize the calling (invoking) hierarchy of the Project, where the root is always Process (in REFrameWork) if the hierarchy grows too large.
Projects and Sub-projects
- Upper Camel Case naming
- Group by department using a prefix: E.g. AP_, AR_.
- In case the process is automated using sub-processes (using multiple packages for the same business process, like using Dispatcher and Performer), use the business process code as the next prefix.
A good and consistent naming strategy must be used when defining the Orchestrator entities.
- Development machines: DEV_[Name of developer in upper Camel Case] E.g. DEV_DanielDines .
- Test machines: TEST_[Machine Name][Robot Number].
- Prod machines: [Machine Name][Robot Number]
An environment links together multiple robots that are running the same process. Hence, the naming will include a combination from robots and projects:
- Use prefix DEV_ or TEST_ or PROD_.
- Group by department using a prefix: E.g. AP_, AR_.
- In case of sub-processes, use the business process code as the next prefix
- For normal assets: [Department][Project code][Asset Name] E.g. AR_CA_MappingTableURL.
- For credentials: C_[expiration period][Department][Project code]_[Asset Name] E.g. C_180_AP_SC_SapCredentials.
[Department][Project code][Queue Name] E.g. AR_CA_ExcelItems
You might be interested in the following courses:
Course Category: Robotic Process Automation
This is an advanced guide to best practices that need to be followed in developing bots using Automation Anywhere. This course provides an introduction to common bot design guidelines and standards. Avoiding common mistakes and including these processes and considerations in your bot design standards, creates bots that are clean, easier to read, test, maintain, and are stable. Most of […]
Robotic Process Automation(RPA) is a kind of automation where a bot performs human’s task in completing rules based jobs. Robotic Process Automation refers to a style of automation where a machine, or computer, mimics a human’s action in completing rules-based tasks. In traditional workflow automation tools, a software developer produces a list of actions to automate a task and interface to […]