🏆Capstone project: Project: Rebuild the Interactive Menu with Functions

In Chapter 7, you built an interactive menu as one long loop. It was a successful program, and its growing body revealed the next design problem.

Now you will rebuild the same behavior with functions.

This is a refactor: changing the structure of working code while preserving what it does.

Compare the two shapes

The original menu placed every detail inside its branches:

if command == "add":
    new_item = input("What should I add? ").strip()
    items.append(new_item)
    print(f"Added: {new_item}")
elif command == "list":
    if len(items) == 0:
        print("The list is empty.")
    else:
        number = 1
        for item in items:
            print(f"{number}. {item}")
            number += 1
elif command == "count":
    print(f"Items stored: {len(items)}")

The refactored loop delegates those actions:

if command == "add":
    add_item(items)
elif command == "list":
    show_items(items)
elif command == "count":
    show_count(items)

The total program is not necessarily shorter. It is easier to navigate:

• run_menu explains the overall conversation.

• add_item explains adding.

• show_items explains listing.

• show_count explains counting.

Each function can be read and checked on its own.

The four functions

add_item(items)

Ask exactly:

What should I add? 

Clean the answer with .strip(), append it to items, and print:

Added: read a book

The list passed into the function is the same list the menu uses. Appending to it changes that list, so later commands see the new item.

show_items(items)

If the list is empty, print:

The list is empty.

Otherwise print every item on a numbered line starting at 1.

show_count(items)

Print:

Items stored: 2

using the list’s actual length.

run_menu(items)

This function owns the loop. It asks exactly:

Command (add, list, count, quit): 

Clean the command with .strip().lower().

For add, list, and count, call the matching function. For quit, print Goodbye. and break. For anything else, print I do not know that command. and continue.

The top-level program

After the definitions:

1. choose a non-empty menu_title;

2. create an empty list named items;

3. print the title;

4. call run_menu(items);

5. print Final count: followed by the final length.

Those five lines describe the lifetime of the program without explaining every menu action.

Build and test in pieces

Do not write the entire project before running it.

1. Write show_count, then call it temporarily with a list of two values.

2. Write show_items, testing both an empty list and a list with two values.

3. Write add_item, call it once, and inspect the list afterward.

4. Write run_menu with only the quit branch.

5. Add one command branch at a time. Each branch should delegate to its function.

6. Remove temporary calls, then run the complete top-level program.

Work through this sequence:

1. list while empty;

2. add a first item;

3. ADD in capital letters and add a second item with spaces around it;

4. count;

5. an unknown command;

6. list;

7. quit.

The behavior should match your Chapter 7 project. The difference is what the code communicates.

Read the result at two levels

First, read only the top-level lines and run_menu. Can you understand the whole program’s plan?

Then open show_items. Can you understand listing without reading the input and add logic?

That separation is the outcome of this chapter. Functions are not just a way to avoid copying code. They let you design where each piece of knowledge belongs.

If your plan includes Guided, you can ask Monty:

Read my function names and tell me whether each one has one clear responsibility. Point to one boundary I should reconsider, but do not rewrite the project.

You now know how to turn a working sequence of instructions into named, testable operations. Chapter 9 will give those functions richer information to work with by introducing dictionaries and comparing collection types.