2B — Structure It

Build it so it's organized, documented, and hard to break.

This Level Is for You If…

• You're comfortable with the Unit 1 skills in your language, and Unit 1 didn't stretch you much.
• You've met classes (or your language's equivalent) and error handling, in Extended Unit 1 or somewhere else.
• You want to use them in a real program, not just a practice exercise.

What You'll Build

A console program from the problem menu: a calculator-type tool, a quiz engine, or a simple tracker. This time it's designed around at least one class, or your language's equivalent (a struct, an object type, or a module with its own data).

The class should model the main "thing" in your program, like a Quiz, a Tracker or a Converter. It shouldn't just be a wrapper around a function you already had.

Requirements Checklist

Your finished project must include all of these. (Ticking the boxes is just for you, it doesn't save.)

• Everything on the 2A list, except input validation now uses your language's error handling where it fits
• At least one class (or equivalent) with a constructor or setup step, attributes, and at least two methods that do real work
• Error handling around every user input and any conversion that can fail, with a helpful message instead of a crash. In Python this is try/except; other languages have their own version.
• Documentation comments on every function, method and class: what it does, its parameters, and what it returns. In Python these are docstrings.
• A debugger walkthrough in your README: a screenshot of a breakpoint, the variable values you saw, and what that told you about a bug
• A test table with at least 8 tests, including 3 edge cases (empty input, very large numbers, unexpected text)
• AI Collaboration section filled in

On AI and tutorials: fine to use, as long as your AI Collaboration section records what came from them. When your teacher calls you up, you should be able to explain your class and every method in it.

Checkpoints at 2B

Remember to start each checkpoint commit with CP1:, CP2: or CP3:, and push before your teacher calls you up.

How to do the debugger walkthrough

1. Pick a bug you actually hit, or a spot where you weren't sure what your code was doing.
2. Set a breakpoint on the line before things go wrong. In VS Code, click just left of the line number to add a red dot.
3. Start your program under the debugger. For Python, press F5 and choose Python Debugger → Python File. For JavaScript in the browser, open DevTools (F12), go to Sources, and click the same line number.
4. Look at the variables panel. Step one line at a time, and watch the values change.
5. Take a screenshot, and write down what the values were and what that told you.

The last sentence is the important part. "Here's a breakpoint" isn't a walkthrough. "score went back to 0 on every question, so I realized I was resetting it inside the loop" is.

When You're Stuck

• Revisit your Extended or Unit 1 notes on classes and error handling. Python students: your notebooks in 1_foundations/practice. Other languages: your Unit 1 concept log.
• Use the debugger, not print statements. Set a breakpoint on the line before things go wrong and watch the variables.
• If your class feels pointless, ask yourself: "What data does this thing hold, and what can it do?" If the answer is "nothing" and "one thing," it might not need to be a class yet.
• Keep error handling small. Wrap the one line that can fail, not the whole program. Otherwise you'll hide real bugs.

Done Looks Like…

Your main program reads almost like plain English, because the class does the heavy lifting. Bad input gets a friendly message every time. Someone could read your documentation comments and use your class without reading the code inside it.