Things that we have learned over time

· Always use descriptive variables and parameters (I don’t care about length if it makes it easier to read what is happening). Use camel case.

· Name the activities with a helpful name, remove meaningless boilerplate

· Whenever logic is not obvious – add an annotation

· Add comments for warnings to other developers

· Group activities with properly named sequences

· Rename the outermost sequence that is automatically generated with a name showing that it is the top level, otherwise variable scope is confusing

· Remove default parameters (only use default parameters for initial testing), if the value is always the same use variables

UIPath says there are 2 ways of looking at this, but I have found this to be a source of bugs

· Parameters should have IN_, OUT_, INOUT_ prefix so there won’t be confusion with variables

· No Hardcoded values (e.g. locations on spreadsheet)

To search for hardcoded values, you can do a search on numbers 1,2,3, etc.

· If you copy and rename a XAML file, go into the file with notepad++ and change the original name that is stuck in the code

· Try to have the expected process in the left pane of an IF statement

· Don’t store workflows under the root

· Use folders to group functionality

· Soft close applications and then only kill if the process is still there

UIPath Suggestions

· Don’t use hardcoded delays

I believe there is a time and place for small delays. Code to check for existence of elements can clutter the code. Also there are less obvious things that we can wait for like a change in value

· When using typeinto use emptyField

· Use simulated click

UIPath’ s reason is for attended solutions. We have found that this helps for forms off-screen. However, this won’t always work and testing must be done (sometimes the program is handling onKeyDown events etc.)

· Use flowcharts instead of nested if’s

1 comment:

Add comment