Naming Rules and Best Practices

[atomic]

How do you name your variables, arguments and so on?

This describes it a little:

Naming Rules

This is from 2017:

Variables, arguments and workflows naming - best practice

Hello everyone, I am a bit confused about the best practices of naming variables. From what I can remember the best practice for variable naming was camel case. After following the Academy 2 in the walkthroughs I could find different naming styles: dt_Students, StudentField (not the actual variables, just examples, can’t remember exactly the names). So, what is the best practice in naming variables, arguments and workflows? Best regards, Bogdan

REF uses upper Camel Case for the variable naming.

ST-NMG-001 - Variables Naming Convention

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.

Example of Regex expression: ([A-Z]|[a-z])+([A-Z]|[a-z]|[0-9]) .
Valid variable names: Hello1World2 , helloWorld , Hello1World .
I’m used to use lower Camel Case but then it would not look good because the REF uses upper Camel Case for its variables.

How do you do it and can you give examples how you name your variables(different types(string,bool/element exists, datatable, int), arguments (different types(string,bool/element exists, datatable, int), and so on.

[Palaniyappan (Forum Leader)]

@atomic

different types(string,bool/element exists, datatable, int), arguments (different types(string,bool/element exists, datatable, int), and so on.

Let’s go one by one

First let’s start with variables
These are something I follow to have a easy understanding of what that variable is actually and we can easily identify the variable type on seeing the name itself

If it’s a string variable then name it as
str_variablename

If it’s integer
int_variablename

If it’s Boolean
bool_variablename

If it’s datatable
Dt_variablename

If it’s Datetime
date_variablename

If it’s list variable
list_variablename

Same applies for arguments just with argument direction name in front of variable names

Say if you variable is named as str_name then it’s corresponding argument name will be

in_str_name - if it’s IN direction
out_str_name - if it’s OUT direction
inout_str_name - if it’s IN/OUT direction

Hope this would help you

Cheers @atomic

[atomic]

Okay, I have heard that the prefix for most of the above could be unnecessary because one can easily see what the type is in the “panel view”.

The only thing i have used the prefix for are datatables(dt_Datatable).

[Palaniyappan (Forum Leader)]

@atomic

above could be unnecessary because one can easily see what the type is in the “panel view”.

For every variable you see if you go and refer the variable panel it will take more time
Say you have 100 variables in your workflow and you want to know for one specific variable, it will take more time to go and search in panel

That’s why to make it easier we add it with variable name itself
So on just seeing the name itself we can understand it’s type

Cheers @atomic

[Palaniyappan (Forum Leader)]

Any further queries on this topic @atomic

[atomic]

Not really but I wish that the official UiPath documentation would have some concrete examples or
guidelines about this.

The only thing I can read from this(below link) is that they are suggestions and one can mix and match upper -and lower case Camel Case in one project. The “Main.xaml”(REF) has values in upper Camel Case(VariableName) but others also uses lower Camel Case(variableName) within the same project.

Naming Rules

I guess its a preference thing.

[Palaniyappan (Forum Leader)]

@atomic

guess its a preference thing.

Yeah absolutely @atomic