Home

RPA Lint

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.

Suggesting new rules

If you'd like to suggest a new rule, please create a new issue to let us know.

List of applied workflow rules

The rules that are applied by the app at the workflow level are outlined below. Unless otherwise stated all rules report an error condition.

Arguments must have annotations

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.

Argument names must start with an upper case letter

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.

Main flowcharts must have an annotation

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.

Main sequences must have an annotation

A workflow that is contained in a sequence must have annotation. For the same reasons that apply to main flowcharts.

No arguments or variables with the same name

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.

Public workflows must have annotations

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

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.

Variable names must start with a lower case letter

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.

Workflows should not contain code activities

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.

List of applied project rules

The rules that are applied by the app at a project level are outlined below. Unless otherwise stated all rules report an error condition.

No outdated project dependencies

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.