-
Notifications
You must be signed in to change notification settings - Fork 3
Home
This app is used by the Robotic Process Automation (RPA) team at Flinders University to lint our RPA projects against an agreed set of rules. We apply these style rules so that our automations are consistent.
We use UiPath to develop and manage our automations.
This app, developed using Node.js, uses static analysis techniques to check the XAML code and project settings against our agreed rules.
If you'd like to suggest a new rule, please create a new issue to let us know.
The rules that are applied by the app at the workflow level are outlined below. Unless otherwise stated all rules report an error condition.
All arguments must have an annotation. An annotation is important as it makes it easier to understand the purpose of an argument. Without needing to deep dive into the code.
All argument names must start with an upper case letter. This makes it easier to identify when an argument is used in an expression, as opposed to a variable.
A workflow that is contained in a flowchart must have annotation. It is expected that the annotation explains the purpose for the workflow. Thereby contributing to the documentation for the project.
A workflow that is contained in a sequence must have annotation. For the same reasons that apply to main flowcharts.
Argument and variable names are case insensitive in UiPath projects. Therefore it is possible to have an argument and a variable with the same name. If this happens unexpected behaviour is likely.
Workflows that are part of a library project and exposed publicly must have annotation. This annotation will appear as a tool tip when an RPA developer hovers over the activity in UiPath Studio.
Variables must have annotations. An annotation is important as it makes it easier to understand the purpose of an variable. Without needing to deep dive into the code.
All variable names must start with a lower case letter. This makes it easier to identify when a variable is used in an expression, as opposed to an argument.
Ideally workflows should not contain the activities that allow the use of code blocks, invoke methods, or invoke power shell scripts. These types of activities make the workflows harder to maintain and can hide complexity.
There are times when it is necessary to use these activities to achieve the goals of the workflow. For this reason this rule raises a warning and not an error.
The rules that are applied by the app at a project level are outlined below. Unless otherwise stated all rules report an error condition.
If the app is invoked with the --dep-check option the list project dependencies will be analysed. The metadata for each dependency will be retrieved from the official NuGet repository. Any specified dependency version that does not match the latest version will be reported as an error.