Chapter 6
Custom Commands

In this chapter you will learn:

• How to split complex problems into simpler ones which are easier to solve.
• How to define custom commands using the keyword def.
• How to use the optional return statement.
• The Second Maze Algorithm of robotics.
• That the shortest program may not always be the most efficient one.
• How to define new commands locally within the body of other commands.

6.1. Why are custom commands useful?

Today, Karel needs to collect 25 computer chips which form five stars:

The following program will solve the task, but it would not get you hired as a software engineer. Look at it first, and then we will explain what is wrong with it:

The problem with this program is that it contains a 10-line section which was copied and pasted five times:

This is the section of the code which actually collects the pattern of five chips.

Copying and pasting code makes the program not only long and cumbersome to work with, but also extremely prone to mistakes. Imagine that the pattern of the chips changes:

Then the above code would have to be redone at five different places (!) Since programmers are only human, they are likely to make mistakes. And changing the same code at five different places makes the likelihood of making a mistake extremely high.

6.2. Defining a custom command star

The correct approach is to define a new command for the repeated functionality. Let’s call it star:

Notice that custom commands are defined using the keyword def which is followed by the name of the new command. Then, indented, comes the body of the command. The following image shows where Karel should be when the command star is executed, and then the robot’s position after the command finishes:

6.3. Assembling the solution of the main task

Recall that the main task is to collect all 25 chips:

But how can the custom command star be used to solve it, when Karel is far away from the first star of chips?

The answer is - before executing the command star, we will program Karel to get there! In order to stand on the first chip of the first star, the robot needs to make four steps forward, turn left, and make one more step:

After executing this initial code, Karel is ready to execute the command star for the first time.

Next, in order to get ready for collecting the second star of chips, Karel needs to turn right, make 6 steps forward, and turn left:

After executing this code, he is ready:

Now you should able to figure out the rest! Write down the commands Karel needs to get ready to collect the third, fourth, and fifth stars of chips. The final program is as follows:

6.4. Collecting water bottles

Today Karel faces another complex task - to collect 27 water bottles which are stored in three crates:

As you already know, it would not be a good idea to go ahead and start writing code right away. Let’s think about it first, and figure out a suitable subtask which is easier to solve than the main task.

Here is a good candidate for such a subtask. Let’s call the new command get9:

This time, let’s work like an experienced software engineer, and solve the main task first. We know that the subtask is a routine thing to do, so we can leave it for later. The main program is below. Step through it in your mind to verify that it is correct!

This was a piece of cake - which tells us that the subtask was chosen really well! It remains to write the body of the new command get9. But you know what? We can still simplify it by splitting it into three smaller subtasks, where one subtask will be to just collect a row of three water bottles. Let’s call the new command get3:

The following code will do it:

And now, the new command get9 is easy to write:

Finally, let’s put everything together and write the solution program for the main task. The program will consist of two custom commands and a main program:

6.5. The optional return statement

Every custom command can (but does not have to) contain one or more return statements. The return statement terminates and exits the custom command. For example, the command get3 from the previous section could be written as follows:

6.6. Arcade game

Karel’s next task is to pass through the entire maze, collecting all gold nuggets and gems:

This is a complex task, so why don’t we solve a simpler subtask first. It will be much easier to just pass through one floor, left to right, collect all nuggets and gems, and if not at home, then find the opening to the next floor up. Let’s call the new command floor:

As before, first let’s solve the main task assuming that we already have the command floor. The new command will be easy to define later:

And here is the new command floor:

By putting the pieces together, we obtain the final solution program:

6.7. Second Maze Algorithm (SMA)

You already know the First Maze Algorithm of robotics which allows Karel (or any other robot) to pass through unknown mazes. The Second Maze Algorithm (SMA) allows robots to follow an arbitrary winding wall or a line on the ground. Imagine that Karel is in the jungle, and he has to follow a winding line of tree branches to his home square. He stands next to the line which is on his left-hand side:

The Second Maze Algorithm of robotics will guide Karel safely to his home square:

It can be translated to the following code:

Let’s have a closer look at how the algorithm works! At the beginning, the line goes straight forward:

On line 2, Karel will turn left:

The while loop on line 3 will do one cycle, and so Karel will turn right once:

Finally, on line 5, he will make one step forward:

OK, that worked! After two more steps forward, Karel will arrive at a right turn:

On line 2, he will turn left:

Then, the while loop on line 3 will do two cycles:

And finally, Karel will make one step forward on line 5:

After this, the robot will make another right turn and two steps forward. Then the situation becomes more interesting because there is no wall on his left. BTW, this case is why the algorithm begins with a left turn, in case you were puzzled about it:

So, on line 2 Karel will turn left:

The body of the while loop will be skipped because there is no wall in front of the robot, and he will just make one step forward on line 5:

Now the situation repeats itself because there is no wall on Karel’s left. Hence, on line 2 he turns left:

Because there is no wall in front of him, the body of the while loop will be skipped again, and on line 5 he will make one step forward:

Woo-hoo, almost there! After a few more steps and one more right turn, Karel arrives at a left turn:

On line 2 he turns left:

Since there is a wall in front of him, the while loop will make him turn right once:

And on line 5 he makes one step forward:

You already know this situation - Karel does not have a wall on his left. On line 2 he turns left:

Then, because there is no wall in front of the robot, the body of the while loop is skipped, and Karel just makes one step forward:

6.8. Right-handed version of the SMA

Like the First Maze Algorithm, also the Second Maze Algorithm has a right-handed version. It is useful when Karel needs to follow a wall or line which is on his right:

The algorithm is symmetric to the SMA (just switch "left" to "right" and vice versa):

Here is the corresponding code:

6.9. Rock climbing

Today, Karel will climb some rocks! His task is to collect all the beepers and enter his home square. The shape of the rock is random, and so is the number and positions of the beepers on it:

This task is perfect for the Second Maze Algorithm (right-handed version). Just executing Program 6.14 will make Karel follow the contour of the rock ("climb on the rock") and get to his home square. So, the only change we need to make, is to check for a beeper after each step the robot makes:

6.10. Program length vs. efficiency

You already know that a well thought-out program usually is shorter and more elegant than a program which was written hastily. However, program length is not the only thing that matters. Even more important is efficiency.

In this section we will show you that the shortest program may not always be the most efficient one.

Today, Karel is collecting pearls in the ocean:

This task is perfect for the Second Maze Algorithm (right-handed version) - Karel just needs to follow the wall on his right-hand side, and it will lead him to his home square. The solution program is practically the same as Program 6.15, the only difference being that the robot is looking for pearls instead of beepers:

This program needs 503 operations to collect all pearls and get Karel home. Save this number for a future comparison!

Next, let’s solve the task differently. We will write a new command column for the robot to collect all pearls in the column above him, and get ready below the next column. Then, the main program will just loop over all columns:

As you can see, this program is longer than the previous one - it has 16 lines of code as opposed to 7. However, it provides a solution which is much more efficient. It collectc all pearls and gets the robot home with only 242 operations!

6.11. Writing monolithic code vs. using custom commands

Sometimes it is not obvious whether one will gain anything by introducing a custom command. For illustration, let’s return to the five stars of chips from Section 6.1 (page 490), but now the stars will form a regular repeating pattern. The task is the same - collect all the chips!

The code can be written as one monolithic piece, without defining any custom commands:

This code is very dense, but it does not contradict any good programming practices - there is no part which would be copied and pasted at multiple different places in the program (as it was in the original task in Section 6.1). The comments make it readable, so it is a good code.

Now let’s solve the same task using the custom command star from Section 6.1. And moreover, we will define another new command next for the robot to move to the next star or to the home square:

The latter program had 21 lines (not counting empty lines and comments) while the former only had 17. This is not a huge difference. On the other hand, the latter program is so well readable that the main program does not need any comments - it is completely self-explanatory. Readability matters. If we had to pick up our favorite, then the slightly longer but much more readable program would definitely be our choice.

6.12. Defining commands inside other commands

It is possible in Karel to define commands within the body of other commands. This feature was implemented for conceptual compatibility with Python. Its usefulness becomes clear in large, complex programs where it helps keep code better organized.

For illustration, let’s return to Section 6.4 (page 516) where Karel was collecting water bottles from three crates. The solution Program 6.8 defined new commands get3 and get9. Notably, the command get3 was only used within the body of the command get9 and nowhere else. Therefore, it can be defined locally in the body of the command get9:

If we tried to call the command get3 outside the body of the command get9, the program would crash with an error message. In larger programs, limiting the validity of commands helps improve code structure.

6.13. Create your own Karel language!

Being able to define your own commands is powerful. If you like, you can now create your own language for Karel, adding all the commands which you were missing! For example, the Karel language does not have a command to turn around 180 degrees, so let’s add it:

With this new command in hand, many algorithms become simpler to implement, such as the First Maze Algorithm:

Speaking of the First Maze Algorithm, why don’t we just define a new command move to move one step forward in the maze:

Then, passing through an unknown maze becomes extremely simple:

Now let’s change the subject. If your native language is different from English, you can make Karel speak your language! For example, "get" is "ukuthola" in Zulu:

6.14. Review questions

Friendly reminder - for every question either none, one, or several answers may be correct.

Table of Contents

• About
• 1. Introduction
• 2. Basic Commands
• 3. Counting Loop
• 4. Conditions
• 5. Conditional Loop
• 6. Custom Commands
• 7. Variables
• 8. Functions
• 9. Text Strings
• 10. Testing Your Programs
• 11. Boolean Values, Variables, Expressions, and Functions
• 12. Randomness and Probability
• 13. Lists
• 14. Recursion
• 15. Advanced Applications
• Appendix A. Karel App in NCLab
• Appendix B. Self-Paced Karel Course in NCLab