Programming Fundamentals Consolidation Project

Consolidating Sequences 1–2: Programming Fundamentals

This lesson is different from the ones before it: there's no new concept to learn. Instead, you'll combine everything from Sequences 1 and 2 — data types, arithmetic, relational and Boolean operators, variables and constants, string manipulation, input/output, and random number generation — into one complete, working Python application.

Before you start

Make sure you can confidently explain: data types and why you'd choose one over another; arithmetic and relational/Boolean operators; the difference between a variable and a named constant; basic string manipulation; keyboard input and file input/output; and random.randint/random.choice. If any of those feel shaky, revisit that lesson first — this project assumes you can combine them, not learn them for the first time.

Choose one project brief

Option A — Menu-Driven Quiz Application. A program that presents a menu (using string output and input), asks the user a series of questions, uses relational operators to check answers, keeps score using a variable, and uses a named constant for the pass mark. Extension: read questions from a file instead of hard-coding them, and use random.choice to ask them in a different order each run.

Option B — Interactive Game. Any game that combines random number generation (e.g. a number-guessing game, dice game, or expanded Rock-Paper-Scissors) with score-keeping (variables), input validation (relational/Boolean operators and string checks), and a named constant for something fixed (e.g. the number of rounds, or a winning score threshold).

Plan before you code

Before writing any Python, sketch your program's structure using a flowchart or plain pseudocode (both introduced properly in Sequence 5, but a rough version now is good practice): what does the menu look like, what inputs does the program need, what decisions does it make, and what does a completed run look like? Planning first — rather than typing code and hoping it works — is a habit examiners and NEA moderators consistently reward, and it saves debugging time later.

Requirements checklist

Your finished program should demonstrate:

• At least two different data types used appropriately (e.g. a string for a name, an integer for a score).
• At least one named constant (ALL_CAPS) for a value that shouldn't change during the program.
• Relational and/or Boolean operators used in a real decision (not just printed as an example).
• String manipulation — formatting output or validating text input.
• Keyboard input, and file input or output for at least one piece of data (e.g. saving a high score, or logging results).
• Random number generation, used meaningfully (not just printed once and ignored).
• Comments and meaningful identifier names throughout.

Testing your program

Run it more than once, deliberately trying to break it: what happens with unexpected input (a letter typed where a number is expected)? Does the random element actually vary between runs? Does the file update correctly if you run the program twice in a row? Finding and fixing a problem yourself, before anyone else sees it, is the single most useful debugging habit you can build this early in the course.

Self-assessment

Once finished, check your own work honestly against the requirements checklist above, and write two or three sentences noting: what you're most pleased with, and what you'd improve with more time. This kind of evaluation — not just "does it run", but "how well does it meet the requirements and where are its weaknesses" — is exactly the skill the NEA in Year 13 will ask you to apply to a much larger project.

Looking ahead: Sequence 3 (Modular Programming) will show you how to restructure a program like this one into smaller, reusable functions — worth remembering as you write this project, since a program built as one long block of code is harder to modularise later than one written with natural, well-named sections from the start.