Fixing your own programs, and what next

What you will be able to do

After this lesson you can

• follow a checklist when a program does not work,
• tell the three kinds of fault from each other,
• find a fault with a trace table and a debugging print, and
• say what to learn next.

A program that does not work is normal

Every programmer, on every day, writes programs that do not work at first. The difference between a beginner and an expert is not that the expert makes no mistakes. It is that the expert has a method for finding them. Here is the method.

The three kinds of fault

1. A syntax error. Python cannot read the line. The program does not start. The message names the line and often the problem: a missing colon, a bracket that is not closed. To fix it, read the line, and the one above it.
2. A run-time error. The program starts, and stops in the middle with a message such as NameError, TypeError, IndexError or ValueError. To fix it, read the message from the bottom. It says the kind of error and what went wrong. Above it is the line.
3. A logic fault. The program runs to the end and shows an answer, but the answer is wrong. This is the hardest, because Python gives no message. To fix it, compare with the expected answer, and follow the program by hand.

The checklist

When the program does not work, go down this list, one step at a time.

1. Read the message. From the bottom. Name the error kind, and the line.
2. Look at the line, and the line above it. Many syntax errors are really in the line above.
3. Make the fault small. Use the smallest input that still shows it: a list of two items instead of twenty.
4. Know what you expect. Work out the right answer by hand, before you look at the output.
5. Follow the program by hand. Write a trace table: the values of the variables, round by round.
6. Print the values inside. A print in the loop shows what is happening. Remove it when done.
7. Check the edges. The first item, the last item, zero, an empty list, the number that is exactly at a limit.
8. Change one thing at a time, and run the program again. If you change three things, you do not know which fixed it.
9. Explain it aloud. Tell a friend, or a toy, what each line does. Often you find the fault while you speak.

The checklist in action

This program should show the average of the positive numbers only. The positive numbers are 4, 9 and 7, so the expected answer is 20 divided by 3, about 6.67.

Now think about a case that the program does not handle. What if the list has no positive number, such as [-1, 0, -5]? Then count stays 0 and the last line divides by zero: ZeroDivisionError. This is an edge case, and the checklist told us to look for it. The cure is an if count > 0: before the division, with a message for the other case.

The expected answer, n * (n + 1) // 2, comes from mathematics, not from the program. That is what makes it a fair check.

Make the program easy to debug

• Small functions. A function that does one job can be tested alone, so a fault is found in one place.
• Good names. total and count tell you what the numbers mean. a and b do not.
• Comments for the why, not for the what.
• Test tables. The test of a function is a table of inputs and expected answers.
• Save a working version. Before you change a program that works, copy it.

What next?

You have finished the Foundations. You can store data in variables, make decisions, repeat with loops, keep many values in lists, and organise a program with functions. You have built three programs. That is the core of programming. The next level, Python Essentials, goes further:

• Dictionaries, tuples and sets: more ways to keep data.
• Handling errors with try and except, so that a wrong input does not stop the program.
• Modules: using code written by others, and writing your own.
• Searching and sorting, and recursion: thinking about how to solve a problem.
• Working with text and larger projects.

The best way to learn is to build. Choose a small project that you care about: a quiz for your class, a unit converter, a game, a tracker for your own marks. Plan it, build it in small steps, test it, and show it to a friend.

Common mistakes

• Changing many things at once.
• Guessing, instead of looking at the values.
• Reading only the top of an error message. The useful line is at the bottom.
• Not knowing the expected answer. You cannot find a fault in an answer you cannot judge.
• Giving up before you try the checklist.

Practice

Start with two quick questions. Each New numbers gives you a fresh one, so you can practise as long as you like.

Then the labs and the problems:

1. Warm-up. Open the lab Fix the program. A program has a fault, the checker names the cases that fail, and you find the line.
2. Build. Open the problem Trace the guessing game and fill in the trace table.
3. Stretch. Take one of your own programs from this course, break it on purpose in three different ways, and name the kind of fault each time.

Remember these

• Three kinds of fault: syntax errors, run-time errors, and logic faults.
• Read the message from the bottom. Make the fault small. Follow the program by hand.
• Print the values inside the loop, and remove the prints when done.
• Check the edges, and change one thing at a time.
• Small functions with tests make a program easy to debug.

Check yourself

Try each one on your own first. If you are stuck, open a hint. Then check with Show the answer.

1. Which kind of fault gives no error message?

2. Which line of an error message is the most useful?

3. Why change only one thing at a time?