Variables, arguments and workflows naming - best practice

Help
,
1

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

2 Likes
2

Hi Bogdan,

Screenshot_48
Screenshot_481000×694 111 KB

11 Likes
3

Thank you Ovi, really appreciate it.

Best regards,
Bogdan

4

hi Ovi

I have a question regarding this,

the naming convention within the best practise document differs from the framework and guidance within the Academy 2 modules by quite a bit, is there an updated gitHub which has the correct naming convention for the framework?

kind regards
Fred

5

Hi,

The guide doesn’t really touch on this (maybe it’s just preference), but I find it very beneficial to start every variable with something that identifies its type. (For example, arrData, dtData or drLineItem, nItemCount or intItemCount, boolExists, or oFilepath or strOutFilepath)

The benefit is that you can find your variable quicker by sorting or you can type the first letter and it will list all the variables. This way you don’t need to remember the variable name. Most beginner programming courses suggest that you must use the “type” on the front like int, lng, str, bool, or dt, but sometimes you might want to make an adjustment to that in order to separate, for example, temporary variables from variables that store pertinent information.

That’s my opinion anyway.

Regards.

1 Like
6

Hi Clayton,

This is a very good point and I am curious what UiPath people think of it? This is what I usually use in my projects.

Best regards,
Bogdan

1 Like
7

For weakly-typed languages, sure.
But in a strong-typed language, System Hungarian Notation is redundant and generally shunned away. Especially when generics entered the field.
With UiPath’s current implementation (VB.Net and no late binding), you always know what is the type of the variable by just looking at the variable pane.

[Just by the way, but the type-prefix naming convention was actually a misunderstanding and the creator never intended it to be that way. Original Hungarian Notation prefixes described semantics of the data, not it’s actual compiler type (check here - Hungarian notation - Wikipedia). It’s also specifically discouraged by Microsoft in their framework design guidelines and was designed for low level languages where types could be ambigious in what they represent.]

There is a lot of edge cases that cannot have easy prefixes with SHN and some of them might be misleading. dt could be DataTable or it could be DateTime. arr is clearly an array, but doesn’t say of what (and I’ll respectively disagree of having arrdrData as a variable name for an array of datarows with data as a variable name).
GenericValue would be a worst offender than it is even now, as it’s by definition of a different type than it’s type.

It also means that you need to rename your variables if you ever change the type and that can lead to bugs - example would be having arrData (which is IMHO a bad name, as it doesn’t say anything about it’s intention) that you then figure out needs be a List as you need to remove/add stuff from/to it. If this is an argument, you’d need to propagate that change through different workflows or break the convention. Both options are bad and can lead to mistakes and/or confusion.

In most of the times I’ve seen it, it brought almost nothing good and at least some bad. If you know you have a collection of mail messages to check, should it matter if it’s an array, list or IEnumerable? With System Hungarian you need to know otherwise you can’t type it in. If you name it foundMessages, you don’t need to know anything else and if you need to know the type, you can check the variable pane or just hover over it and intellisense will tell you.
But what stands without the class-type prefixes is the name describes the purpose of the variable (logic/intent) without hindering the way to achieve it (implementation detail/abstraction).

So this ended a little long, but the summary would be that the info with this kind of prefixing does not (again, IMHO) bring much value and could hinder you.

One rarely mentioned thing is that adding class-type prefixes sometimes leads to bad naming in itself, as prefixes “trick” people to thinking that the name is good, as they “describe” the variable (see arrData above).

In the end, whatever works for you and your team, as with all best practices.

Sidenote/interesting take on Hungarian notations:

10 Likes
8

Those were just examples, and I agree. But there are benefits to prefixes as I mentioned. I’m currently taking advantage, because I don’t need to go searching for what I called a certain variable, or type each letter until I see it listed. If I want to use one of my output variables, like outputDirectory or outputFilepath, I can type “o”; if I just use directory then I might get confused as to which directory that variable is storing.

Also, being descriptive has its limitations, since you don’t want a sentence for the name, so annotations can help describe them better. But, I agree in that the name shouldn’t be too generic.

Another benefit would be if you have a set of data, we can call “FileList”. Let’s say you want to manipulate that variable. Well, depending on if it’s a string, array, table or other types there could be different ways to manipulate it and you need to look it up. If it said arrayFiles, then I know exactly how to use that variable. Or, what if you want a FileList in different formats, like a string and a table, then naming it strFiles and tableFiles would provide a distinction between the two. You could also use “files” as the prefix and go with filesStr and filesTable. I don’t think there’s really a correct way.

I guess my point is that prefixes are helpful, and I’m not really putting focus on the prefix being the variable type, but there are many cases where knowing the type is useful.

On your point if you need to change the type, then that will mess up your code anyway since the different type is used a certain way. You can also use the search to go replace the variable name. But you make a good point.

Overall, I agree, but just think there are good benefits.

Regards.

1 Like
9

Great thread. The best practices guide says this about projects:

“projects should have meaningful descriptions, as they are also displayed in the Orchestrator user interface and might help in multi-user environments”

Do we have any limitations on project (i.e. process) names? Are spaces, quotes, etc. allowed or discouraged in Orchestrator?

Are you all just using multiple word descriptive names for your processes that include spaces?

10

I think the Naming Conventions for Variables and Arguments are very good. It’s easier to tell apart variables and arguments in the workflow. However, seems like UiPath doesn’t follow the Conventions in the productions. Some auto-generated variables are in TitleCase. Also in ReFramework, most of the variables are in TitleCase.

11

Hi Tomy,

The important thing is to have A naming convention and it can evolve in time and can be different from project to project or from customer to customer - everyone has their preferences. The naming convention you see now in the REFrameWork is our latest adopted one, if you refer to the UiPath Development Best Practices document, you will find described exactly this one (using TitleCase for variables). The one posted by @ovi is older, but surely not wrong. It’s just a matter of choosing which naming scheme to use.

Thanks,
Andrei

2 Likes
12

Hi Andrei,
Thanks for your comment.
I suggested people use the old version naming convention at the company. It’s difficult to change it now because there are too many processes to fix if we wanna make the change…

13

There is no real need to change a well established naming convention, I suggest to keep the one you have, as long as the developers use it consistently. Having a naming convention is much more important than which naming convention you use.

Warm regards,
Andrei

2 Likes
14

Andrei, I see. Thanks!

15

Hi, Andrei

Please find the UiPath Official document here:
It gives an example to use TitleCase for an argument such as UserName, and camel case for a variable such as userName. This is opposite to UiPath studio and ReFramework design.

I understand Having a naming convention is OK, so I don’t change it at my company, but when delivering a training, and talk about this part, it good to see the document writing the same thing as UiPath production.

Kind Regards,
Tomy

1 Like
16

Hi Tomy,

It seems the link was removed. I agree, we should have a document easily accessible. Right now there are a couple of references of the UiPath development Best Practices in the UiPath Academy.

Thanks,
Andrei