Create Performance Task

Create Performance Task

1. Key Scoring Elements (The Must-Haves)

   • Lists
     • A list is a collection of items (numbers, words, etc.) that can be stored in one variable. Why It’s Important: The AP rubric requires you to use a list as part of your program. Example: A list of songs in a music playlist (playlist = ["Song A", "Song B", "Song C"]). Don’t just create a list — use it! Add, remove, or update items to show the list is part of the program logic.
   • Procedures
     • A "mini program" that performs a specific task. The rubric wants to see a procedure with parameters, return values, and logic. Your procedure should have parameters (inputs) and return a result. If you forget this, you’ll miss points.
   • Documentation
     • Clear explanations of how your program works. The Create Task requires written responses explaining your program logic. Comment your code as you write it. If you wait until the end, you'll forget why you wrote certain parts of the code.

2. Collaboration (Working with Others)

   • What Counts as Collaboration?
     • Brainstorming ideas with classmates. Getting feedback from a teacher, classmate, or mentor. Reviewing another person’s code for logic errors.
   • What Doesn’t Count as Collaboration?
     • Copying someone’s code. Letting someone else write parts of your code for you.
   • How to Show Collaboration on the Exam
     • Include a reflection in your write-up about how collaboration improved your program. Example: "During the brainstorming session, I discussed possible program ideas with my classmate, and they suggested adding a 'difficulty selector' to my game."
   • Exam Tip: "Make sure you reference collaboration in your written responses. It shows you worked with others to improve your program."

3. Program Design (How to Plan and Structure Your Program)

   • Problem Identification
     • Define the problem your program will solve. Example: "I want to create a quiz app that tracks your score and gives feedback."
   • Flowchart / Pseudocode
     • A visual plan or step-by-step outline of your program logic. It helps you stay organized and ensures you don’t forget key parts (like lists and procedures).
   • Breaking it Into Parts (Decomposition)
     • Break down your program into 3 key parts: Input: What data will the program need? Process: What logic will be used to manipulate the data? Output: What will the program display or return?
   • Exam Tip: "Don’t just jump into coding. Take 20-30 minutes to draw out the flow of your program and plan how you’ll use lists, procedures, and logic."

4. Branch: Debugging (How to Catch and Fix Errors)

   • Common Errors
     • Syntax Errors: Typos, like missing parentheses. Logic Errors: Your program runs, but it gives the wrong answer. Runtime Errors: The program crashes when it runs (like dividing by zero).
   • How To Debug Like A Pro
     • Add print() statements to see what’s happening at each step. Walk through each line and track variable changes. Comment out large sections and run only small parts of your code.
   • Final Debugging Checklist
     • Did I use my list correctly? ✅ Does my procedure have parameters and a return value? ✅ Did I test edge cases (like dividing by zero or entering unexpected inputs)?
   • Exam Tip: "When something breaks, don’t guess. Use print statements and check if the variables are what you expect them to be."

5. Written Responses (Where You Earn BIG Points)

   • Key Written Sections
     • Program Purpose: "What is your program supposed to do?" Data Abstraction: "How did you use a list to manage data?" Procedural Abstraction: "Explain your procedure (what it does, how it works)." Testing: "How did you test the program to make sure it works?"
   • How to write clear responses
     • Be Specific: Don’t just say "I used a list" instead you say what the list holds and how you used it. Use Examples: Show an example of your list, like myList = [3, 5, 7]. Talk About Collaboration: Mention how feedback from a friend/classmate improved your program.
   • Exam Tip: "Your written responses should be so clear that someone who didn’t see your code would still understand what you did."