- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- Variables
- Arguments
- Imported Namespaces
- Recording
- UI Elements
- Control Flow
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Citrix Technologies Automation
- RDP Automation
- Salesforce Automation
- SAP Automation
- VMware Horizon Automation
- Logging
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Test Suite - Studio
- Extensions
- Troubleshooting
Studio User Guide
ST-NMG-001 - Variables Naming Convention
ST-NMG-001
Scope: Activity
Variables in a project should follow a specific naming convention to make it easier to understand the purpose of the variable and to maintain it. The variable name should be meaningful to accurately describe its usage throughout the project.
This rule analyzes all variables in the project and determines whether they follow the specific convention. If not, a message is logged in the Error List panel.
^(dt_)?([A-Z]|[a-z])+([0-9])*$
.
dt_
recommended for DataTable variables, followed by a lower or upper case letter, and then one or more numbers.
HelloWorld1
then it matches the default Regex expression set in this rule.
In the Project Settings window, select the Workflow Analyzer tab. Find the rule and select the rule, as in the image below:
[A-Z]
part of the expression, the search pattern becomes ^(dt_)?([a-z])+([0-9])*$
. Now the rule checks if variables start with a lower case letter and are followed by a number.
[a-z]|[A-Z])
, then the rule becomes ^(dt_)?([A-Z]|[a-z]+[a-z]|[A-Z])+([0-9])*$
, and recognizes HelloWonderfulWorld
as a valid variable name.
The default regex expression for this rule can be changed to another naming convention. Check the list below:
Camel Case
The camel case convention specifies that each word in the middle of the variable name begins with a capital letter, with no intervening spaces or punctuation.
^(dt_)?([A-Z]|[a-z])+([A-Z]|[a-z]|[0-9])
.
Hello1World2
, helloWorld
, Hello1World
.
Pascal Case
The Pascal case naming convention specifies that the variable name must contain concatenated capitalized words.
^(dt_)?([A-Z])+([A-Z]|[a-z]|[0-9])
.
Hello1World2
, HelloWorld
, Hello1World
.