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
