Create Task: Tips and Resources

1. Program Code: One PDF with all of your program code, including comments. You can write the code alone or with a partner.

2. Video: A video, up to 1 minute long, of your program running. You make it on your own.

3. Personalized Project Reference (PPR): Screenshots of a procedure and a list from your code, with no comments. You make it on your own, and you get a printed copy of it on exam day.

• Program code: You can work with one or more partners on ideas, writing, debugging, and testing the code. Once the official task starts, nobody else (including your teacher) can write, debug, test, or fix your code.

• Video and PPR: These must be done completely on your own, with no help from partners or anyone else.

• What your teacher can do: Clarify the directions, help with technical problems (like a broken computer or saving files), help form groups, and step in if a partner is blocking the work. Your teacher can't give feedback on any part of your Create task, or on practice written responses, until all three components are submitted as final.

• No recycled work: You can't submit AP Central samples, samples from your curriculum, or a practice performance task as your final submission.

1. User Input and Output: The program must take input from the user (including actions like clicks or key presses that trigger events), a device, an online data stream, or a file. It must also produce output (visual, audible, tactile, or text) based on the input and what the program does.

2. Data Storage: Use at least one list (or another collection type, like a dictionary) to store a collection of data that the program actually uses to do its purpose. The list has to manage complexity: it makes the program easier to write (doing it without the list would be more complicated) or easier to maintain (if the amount of data changes, you wouldn't have to rewrite much code).

3. Function with Parameters: Write at least one procedure (function) of your own that helps the program do its purpose. You define its name, its return type (if your language needs one), and one or more parameters, and the parameters have to affect what the procedure does. Built-in procedures, event handlers (like onEvent in App Lab or a "when clicked" block in Scratch), and main methods don't count as student-developed.

4. Algorithm Inside the Function: The body of that procedure must contain an algorithm that uses sequencing (steps in order), selection (an if or if/else statement), and iteration (a loop). The if statement and the loop have to change the result, not just be there.

5. Call to the Function: Your program must call the procedure somewhere, and the call has to match how the procedure is defined (for example, it passes a value for each parameter).

• User Interface: Ensure your application has clear input and output fields.

• Data Handling: Use a list or array to manage data within the app.

• Functional Operation: Include a function that accepts parameters. Within this function, use a loop (e.g., a 'for' loop) to iterate through the list and conditional statements (if/else) to handle different scenarios based on the data.

• Ensure the user input can navigate through conditional statements effectively.

• Focus on creating a clean and intuitive user interface to enhance usability.

Example of My Create Task Submission: Jumping Game

• User Input: The game responds to keyboard and mouse inputs, allowing the dog to jump.

• Output: The game visually represents the character's jumps and displays scores.

• Data Management: An array stores the scores, and a specific procedure determines and displays the highest score achieved.

Submitting Your Code to CollegeBoard

• Code Print Tool: https://bakerfranke.github.io/codePrint/
• Why Use It? This tool converts your code into a PDF file with several enhanced features:
• Color Coding: Helps distinguish different parts of the code for better readability.
• Line Numbers: Make your code easier to read and check. You won't need them for explanations, though: on exam day you answer the written responses using only your PPR.
• Highlighting: Lets you draw boxes and ovals around parts of your code. This was made for the old Create task, which asked you to mark code. The current task doesn't ask for any marking, and your Personalized Project Reference must never be marked up (code only).

• What the program code PDF needs:
• One PDF file with all of your program code, including comments.
• Text-based code: print it to PDF, or copy it into a document and save that as a PDF.
• Block-based code: take screenshots of only your code, paste them into a document, and save it as a PDF. Screenshots can't be blurry, and text should be at least 10 point font.
• A comment crediting any code that you (and your partner) didn't write. See the citation section below.
• This PDF is not your PPR. Comments are fine here, but the PPR can't have any.

The Video

• It must show:
• Input to your program (like typing, clicking, or pressing a key)
• At least one part of your program's functionality (what it does while it runs)
• Output produced by your program

• It can't contain:
• Any information that identifies you
• Voice narration. Text captions are allowed, and they're a good way to point out the input and output.

• File rules:
• Format: .webm, .mp4, .wmv, .avi, or .mov
• No more than 1 minute long
• No more than 30 MB

• Scoring: It has to be a real recording of the program running. Screenshots or a storyboard of still images get no credit. If it isn't clear from the video where the input comes from, the scorers check your program code.

The Personalized Project Reference (PPR)

1. Part (i), the procedure: A procedure you wrote that defines its name and return type (if needed), has one or more parameters that affect what it does, and contains an algorithm with sequencing, selection, and iteration.

2. Part (ii), the call: The code where that procedure is called in your program.

1. Part (i), storing data: Code that shows how data gets stored in the list. This can be when the list is created with values (initialization) or when values are computed and added later.

2. Part (ii), using the list: Code that shows the data in that same list being used to help the program do its purpose, like creating new data from it or accessing multiple elements (usually with a loop).

• No comments: Delete every comment from the code before you take the screenshots. Comments or any other course content in the PPR mean a 0 on the whole Create task, including your written responses.

• Code only: No labels, notes, or arrows pointing out parts of your code (like "this is my iteration"). The screenshots should show program code and nothing else.

• Readable: Screenshots can't be blurry, and text must be at least 10 point font.

• Made alone: The code itself can be code you wrote with your partner, but you choose and capture the segments on your own.

• Final is final: You can't change the PPR after you submit it as final.

• When there's more than one, scorers use the first loop and the first if statement in your Procedure section, and the first procedure and the first list unless your answer names a different one. Put the code you understand best first, and leave out extra procedures and lists you can't explain.

• Pick a procedure with a parameter in its header that really changes what happens (for example, it decides which branch of the if statement runs). Some recent errors and testing prompts (2024 Set 1 and 2026) gave no credit if the procedure had no parameter in its header or if the parameter didn't affect anything.

• Make sure the loop and the if statement inside the procedure matter to the result. A loop or condition that doesn't change the outcome is "trivial" and won't earn credit.

• Before you submit, practice a full set of past written response prompts using only your PPR. If you can't answer them from the screenshots, change your code segments.

Exam Day: The Written Response Prompts

• Written Response 1: Program Design, Function, and Purpose: Questions about your program as a whole: its purpose, how it works, its inputs and outputs, its users, how you designed and developed it, and its documentation.
• CED sample: Name an expected user of your program and describe one way your program's design meets that user's needs.
• Recent exams asked you to: describe a valid input and what the program does with it (2024), explain how the program addresses a concern or interest of its users (2024), explain how an output shows part of the program's functionality (2025), describe what the program does with an invalid or unexpected input (2025), and describe documentation that would help another programmer understand a code segment (2026).

• Written Response 2(a): Algorithm Development: Questions about how the algorithm in your procedure works: what a loop or if statement does, what a Boolean expression (with relational operators like > or logic operators like AND) evaluates to, what values make a condition true or make a loop stop, writing or changing an algorithm, and whether two algorithms give the same result.
• CED sample: For the first loop in your Procedure section, give the number of times its body runs. Then describe a condition or error that would make it loop forever. If there isn't one, explain how you could change the loop so it would.
• Recent exams asked you to: describe what the body of your loop accomplishes (2024), describe your if statement's Boolean expression and what happens when it's false (2024), name the Boolean expression in your first if statement and a value that makes it true (or false), and why (2025), and identify the variables and values that make your loop stop, and why (2026).
• Infinite loop tip: a while loop runs forever if its condition never becomes false, for example if the loop never updates the variable it checks (like never adding 1 to i in while i < length of the list).

• Written Response 2(b): Errors and Testing: Questions about errors in your procedure (finding them, causing them, and fixing them) and about test inputs and the outputs you'd expect from them.
• CED sample: Describe a change to the procedure in part (i) of your Procedure section that would cause a run-time error, and explain why it would.
• Recent exams asked you to: write two calls to your procedure that make different parts of its code run and describe what each does (2024), give a call with a different argument that produces the same outcome (2024), describe a change another programmer could make that causes a logic error and how the behavior changes (2025), and write a call with specific arguments that makes your procedure behave incorrectly, and explain why (2026).
• Error types (Big Idea 1): a syntax error breaks the language's rules, a logic error makes the program behave incorrectly or unexpectedly, a run-time error happens while the program is running, and an overflow error happens when a number is outside the range the computer can handle. Each language defines its own run-time errors: in Python, dividing by zero or using an index past the end of a list stops the program, but in JavaScript dividing by zero gives Infinity and reading past the end of an array gives undefined, so neither one is a run-time error there.

• Written Response 2(c): Data and Procedural Abstraction: Questions about your list and your procedure as abstractions: how the list stores data, how a loop goes through it, what an algorithm using it would produce, and how the list and the procedure manage complexity (make the program easier to write, read, or change).
• CED sample: You're given a procedure isEqual(value1, value2) that returns true if the two values are equal and false otherwise. Using your list, explain in detailed steps an algorithm that uses isEqual to count how many times a certain value appears in the list. It has to be detailed enough for someone else to write the code.
• Recent exams asked you to: explain an algorithm that uses a given procedure, checkValidity, to check whether every element in your list is valid (2024), explain how your procedure's parameters manage complexity (2024), explain how your list code would have to change if several elements were added to the end of the list (2025), explain how writing some functionality as a procedure makes the program easier to maintain (2025), and explain how your list manages complexity and how your part (ii) code would have to change without it (2026).

1. Create a variable count and set it to 0.

2. Go through every element in scores, one at a time, from the first element to the last.

3. For each element, call isEqual(element, target). If it returns true, add 1 to count. If it returns false, leave count the same.

4. After the loop has checked every element, count holds the number of times target appears in scores. Return it or display it.

• Answer every part of the prompt. Each prompt is worth 1 point, and you only get it if you meet every part of the scoring criteria.

• Scorers only grade what you write, so be specific. Use the actual names of your procedure, parameters, variables, and list, and give actual values when a prompt asks for them (for example, "when score is 12" instead of "when the number is big").

• Everything you say has to match your code. An answer that is implausible, inaccurate, or inconsistent with your program gets no credit, even if it sounds right.

• Know what each task verb asks for:
• Capture: Select a part of your program code that answers the prompt.
• Demonstrate: Give enough evidence to back up your answer.
• Describe: Give the relevant features or characteristics of what the code does or is used for.
• Design: Make a plan for how to meet the program's requirements.
• Explain: Say how or why something happens, using detailed steps of the algorithm, evidence, or reasoning.
• Identify: Just name it. No explanation is needed.
• Implement/Write: Use correct syntax to turn the design into working code.

How the Create Task Is Scored

• The program requirements point is easier than the PPR rules: For this point, the procedure doesn't need a parameter, and the selection and iteration don't have to be in the same algorithm or inside the procedure. The PPR directions still require all of them, though, and the written response prompts ask about the parameter, loop, and if statement in your procedure, so include them anyway.

• Student-developed: Code you wrote, alone or with your partner. It can call existing code or libraries, but built-in procedures and event handlers (in block languages, blocks that start with "when") don't count as yours.

• Collection type: Anything that groups elements into one structure, like a list, dictionary, set, hash table, or database.

• List being used: The program creates new data from the list's existing data, or it accesses multiple elements of the list.

• Selection: Code that runs different statements depending on whether a condition is true or false. If statements and try/except (exception) statements both count.

• Iteration: A part of an algorithm that repeats a set number of times or until a condition is met. Recursion counts as iteration.

• Parameter vs. Argument: A parameter is an input variable of a procedure, defined in its header. An argument is the actual value passed in when the procedure is called.

• Code segment: For text-based code, a continuous chunk of statements inside one procedure. For block-based code, the blocks under one starter ("hat") block.

• Purpose vs. Program functionality: The purpose is the problem your program solves or the creative interest it pursues. Program functionality is how the program behaves while it runs, usually described by how a user interacts with it.

• Input and Output: Input is data sent to the program (touch, sound, images, text, or an event like a click). Output is data the program sends to a device (visual, audible, tactile, movement, or text).

Important Note on Using External Resources

• Images and Code Snippets:
• If you use images or code not created by you, ensure to include a comprehensive citation. This should cover the title, author, source name, date of access, and the URL of the source.

• Assistance from AI or Peers:
• If your project involved assistance from AI tools or peers, it's important to acknowledge this collaboration clearly within your code comments.

• If a person helped, it can only be your collaborative partner(s), and only with the program code. Code you write with a partner doesn't need a citation. Help from anyone else, like a classmate who isn't your partner, isn't allowed once the official task starts.

• Starter code from your teacher: This code was provided as starter code by my teacher.

• Code from an API or open-source project: This code was made freely available by [source of code].

• Code made with a generative AI tool: This code was generated using [Generative AI Tool Name].

• Comments in your code are the preferred way to give credit. If your programming environment doesn't allow comments, add them in a document editor when you capture your code for the PDF. Media (images, sounds) and data sources you didn't make need credit too.

• These comments go in your program code PDF. Delete all comments before taking the screenshots for your PPR.

• Accuracy and Reliability: AI-generated code may be incomplete, potentially biased, or contain errors. It might also introduce inefficiencies or complexities that can complicate the execution and understanding of the code.

• Student Responsibility: It is crucial for students to thoroughly review and understand any code co-developed with AI tools to ensure its proper functionality.

• Code Explanation: Students must be prepared to explain their code in detail during the AP exam, demonstrating a deep understanding of the work submitted, regardless of the use of AI in its development.

Acceptable Programming Languages and Products

• Programming Languages and Environments:
• Alice
• App Inventor
• App Lab (Code.org)
• EarSketch
• Greenfoot
• Java
• JavaScript
• LEGO Mindstorms EV3
• Microsoft MakeCode
• Processing
• Python
• Quorum
• Scratch
• Snap!
• Swift
• TI-Basic