CSC 1001 — Lab 12: File Import & Summary Reports

Intro

This lab builds on last week's lab. You already have a working contact list program that stores first name, last name, and phone number and/or email (plus whatever optional fields you chose to add), lets a user manually enter new contacts while the program runs, and can report counts on request.

This week, you're extending that program in two ways:

• It will be able to load contacts from a file or let the user enter them manually — the user's choice.
• It will be able to produce a fuller summary report on request, not just the individual counts you built last week.

Before you touch your code, you and your partner are going to think like testers. Good programmers don't just make something work for the "nice" case — they think ahead about what could go wrong and plan for it. That planning is what today's Understand section is about.

A reminder on AI assistance: use it to supplement your thinking, not replace it. You'll be asked to explain and defend your choices in Communicate, so make sure you understand every case you plan for and every line you write, even if an AI agent helped you get there.

Submit: your Lab 12 Worksheet and your Lab12.ipynb notebook (extended contact list program).

Understand (with your partner)

Unlike most weeks, today's Understand section doesn't have you tracing or debugging someone else's code. Instead, you and your partner are going to build two lists together, thinking specifically about the contact list format from last week (first name, last name, phone/email, plus your optional fields). You'll use both lists during Do, so don't skip ahead — the quality of your planning here will directly shape how solid your code is later.

List 1: Cases to consider for the file you're importing from

Think broadly about everything that could be different about a file your program tries to read, given that it needs to end up with the same kind of contact data your program already manages. One is done for you as an example:

• The file could be there but be empty.

Work with your partner to come up with at least six more cases, and record them on your Lab 12 Worksheet. Consider things like:

• What the file itself might look like, or fail to look like
• What the data inside the file might look like, even if the file opens fine — remembering that your contacts need a first name, last name, and phone/email
• Anything a person hand-editing a contacts file might do differently than a perfectly formatted file would

List 2: How will you test for these cases?

For each case above, decide how you'll actually check that your program handles it correctly, rather than just assuming it does, and record your plan on your worksheet:

• What test file(s) will you create to trigger each case?
• What should the program do in each case (skip the bad entry, show an error, use a default, etc.)?
• Which cases are common and which are uncommon — should you spend equal effort testing both?

Both partners should agree on both lists before moving on. You'll each work from the same plan, even though you're coding individually.

Do (individually)

Using your contact list code from last week, you will:

1. Let the user choose, when the program starts, whether to load contacts from a file or enter them manually — both options should still work.
2. Add a summary report the user can request at any time. At minimum it should include the counts you already built (total contacts, count by first-name letter, count by last-name letter); add anything else you think makes it more useful as a report rather than a single number.
3. Make sure your program handles the cases your team identified in Understand.

Follow the same four steps you've used all semester:

Step 1 — Requirements

Restate, in your own words, what your updated program needs to do on your Lab 12 Worksheet. Be specific enough that someone else could read your requirements and know whether your program satisfies them.

Step 2 — Subtasks

Break your requirements into smaller pieces on your worksheet. What individual jobs does your program need to do (e.g., "ask the user to choose file or manual entry," "open the file safely," "check whether a line has all the expected fields," "build the summary report text")?

Step 3 — Pseudocode

Write pseudocode for your subtasks on your worksheet before writing any Python. This is where you should account for the cases from your Understand list — if a case isn't handled in your pseudocode, it won't magically appear in your code.

Step 4 — Code

Update your Python in Lab12.ipynb. Keep your pseudocode next to you and translate it piece by piece.

Test your code

Go back to your Lab 12 Worksheet's List 2 and run each test for real. Fill in the "Pass?" column as you go. If something fails, revisit your pseudocode rather than just patching the symptom — figure out where the plan and the code diverged.

You are done with this section once your code passes every test in your plan, including the uncommon cases your team identified.

Communicate (with your partner, same partner as Understand)

Once you've both finished Do individually, come back together and discuss, recording your answers on your Lab 12 Worksheet:

• How did you approach the different cases you identified together? Did you and your partner handle them the same way, or differently? Why do you think that is?
• Did either of you run into a case while coding that you hadn't thought of together? What was it, and how did you handle it?
• How did your testing plan impact your final code? Did writing your tests out before coding change what you built, compared to how you might have written the program without a plan?
• Is there a case either of you still hasn't thought of? Add it to your List 1 table now.

Be ready to share one interesting difference between your two solutions with the class.

Reflect

Answer the reflection questions on the worksheet before turning in Lab12.ipynb and the Lab 12 Worksheet.