Minor but Essential Tips for UiPath Development

This is partly for my own reference.

Coding Standards and Check Tools

To say the most important thing first, more than anything else, it's about making these things part of your coding standards and setting up tools like Workflow Analyzers.

However, no-code is often used not just in code written for formal development projects, but also in environments with ad-hoc licenses where people automate the work right in front of them in their own departments without much preparation. Therefore, besides setting up coding standards and analyzers, I think it's reasonably important for individuals to be at least somewhat conscious of writing in an intuitively easy-to-understand way.

Some methods allow omitting parentheses

But it's better to write them without omitting. That way, you can tell at a glance that it's a method. I understand the feeling of wanting to shorten the code even a little if you're using toString repeatedly, though.

By the way, it doesn't seem like parentheses can always be omitted if there are zero arguments, but I don't know the details. I might find out if I look into the VB specifications.

Reference

• This is why VB.NET is bad! ② (Omitting "()") - Sasakaya

Avoid changing property values for individual activities as much as possible

It's common to think, "It fails occasionally during this transition, so let's increase the Timeout value."

However, primarily, you should first aim to adjust the default values for the entire project. Otherwise, it leads to overall performance degradation or makes individual processes more of a "black box." This is one of the points to adjust your mindset between text-based programming, where user code has high visibility, and no-code, which is layered with visual interfaces.

If you still change property values for individual activities, write annotations (comments)

Furthermore, write comments explaining "why you are changing them." Otherwise, others won't know if it's okay to make further adjustments.

Reflect type names at the beginning of variable names

Instead of InputFileName or InputFileNameString,
use something like str_InputFileName.

In cases like ProductNameList, using lst_ProductName makes it clearer without losing information.

I haven't found very systematic rules on how to abbreviate type names, but there seem to be some loose conventions for major types.

• dt_ → DataTable type. This also appears to be in the Workflow Analyzer rules. Personally, it might be confusing with the DateTime type (which is why coding standards are important).
• str_ → String type
• int_ → Int32 type
• ary_ → Array type
• dic_ → Dictionary type

Should the Boolean type be bool_? Or is is_XXXXXX easier to understand?

I plan to add more as I recall them in the future.