How to Write Well-Structured Robots

A robot is a program so writing well-structured robots is important for the same reasons as it is for writing programs in other programming languages. Writing unstructured robots is like writing books with no chapters and no table of contents. So writing well-structured robots is important because:

A side-effect of writing well-structured robots is that it often also makes robots load faster in Design Studio and generally be more responsive when edited, e.g. when updating the Robot View.

The two main 'tools' that you have at your disposal to write well-structured robots are: Snippet steps and Group steps. Both these two types of steps are used as a way to take a part of a robot, give it a descriptive name and let you pack it up in a single step. In this way you can forget what the part of the robot does in detail and concentrate on other issues of you robot. This is very similar to other concepts found in other programming languages, e.g. methods, function, procedures, etc.

You use a group step to pack up and hide steps that performs a well-defined task that you can give a descriptive name, e.g. Login to site X, Report error. It is important that you can give a relatively short descriptive name to the group step that describes what the steps inside the group does. If you can't then it is probably because they do not perform a well-defined task. Introducing a group step you help document your robot, because the name describes what that part of the robot does.

Although snippet is mainly introduced to share functionality between robots they can also be used inside a single robot to help structure this. If you have a collection of steps in robot that is used in several branches, e.g. by having connections from different part of the robot joining at the start of the steps, you can replace this kind of sharing of steps by introducing a snippet containing the steps.

Let us look at a simple example of one way one may structure a robot using snippets and groups instead of creating additional connections. Assume that our robot looks like this:

Sharing steps using joining connections

The last two steps can be shared by the two branches starting with the steps a and c. In real life you probably have a much larger robot and more than two branches sharing steps in this way and the steps involved may be far apart. This may result in the robot being very hard get an overview of. As a first step towards getting a better structured robot we introduce a snippet step containing the steps c and d. This looks like this:

Sharing steps using a snippet

We can now edit the steps inside the snippet steps and still be sure that our changes are shared in the two branches. We can also further structure our robot by putting each of two branches into a group step:

Grouping the branches steps

Finally, if we close the two group steps we get the following simple robot:

The final result of the restructuring

This resulting robot does two task, one performed by Group1 and the other performed by Group2. By giving these two groups descriptive names the robot has a more logical structure than the original robot.

Admittedly this is a very simple example, but when robots gets beyond a certain size and contain connections crisscrossing the Robot View it is very easy to lose overview of the robot giving a whole new meaning to the word spaghetti code. Restructuring the robot in the manner described above may help regain that overview.