0% found this document useful (0 votes)
46 views40 pages

Variables Conditionals and Functions 24 25 Resources

Algebra 2- Math

Uploaded by

mayah20677
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
46 views40 pages

Variables Conditionals and Functions 24 25 Resources

Algebra 2- Math

Uploaded by

mayah20677
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 40

Variables, Conditionals, and Functions ('24-

'25)
Variables Explore
Resources
Guide to Debugging

Introduction to Debugging
Debugging is the process of finding and fixing problems in code. For most
programs, the time spent debugging far outweighs the time spent writing new
code. Whether students or professional engineers, all programmers get bugs,
and debugging is a normal part of the programming process.

Although students may see bugs as inconveniences to be eliminated as soon


as possible, bugs in student programs should be seen as opportunities to
reinforce positive attitudes toward debugging and persistence, identify and
address student misconceptions, and further develop good debugging skills.
Your role as the teacher is to avoid directly debugging for your students, but to
guide students in better taking advantage of these opportunities.

Reinforcing positive attitudes


Finding bugs is the first step toward fixing them. Programmers deliberately test their code in order to uncover any possible
bugs. Celebrate the discovery of new bugs as students report them in the classroom, framing finding a bug as the first step
to fixing it. Model enjoying the interesting or funny behaviors a bug can cause, such as making a sprite move in
unexpected ways, or distorting an image on a web page. Remind students that if programs all worked exactly as they
wanted the first time, programming wouldn’t be as interesting or fun. Encourage students as they get frustrated, reinforcing
the debugging strategies and students’ self-efficacy as they improve their debugging skills, and talk about the bugs that
you get in your own programs, reminding them that everyone gets bugs, even professional software developers.

Identify and address misconceptions


Often a bug occurs because students have misconceptions around how the computer interprets their code. As part of the
debugging process, have students explain their code, line by line, reminding them that the program is really only doing
exactly as it was told. If the program displays an error message, ask the student to connect the message to what is
happening in the code itself. Prompt them with relevant questions about how the associated programming structures (such
as conditionals or loops) work, and refer them back to previous lessons, worked examples, or documentation when
needed. After students have found the bug, ask them to reflect on what they learned about the associated programming
structures and how they could explain it to a friend with a similar bug.

Develop debugging skills


As students get more experience debugging their programs, they will build the skills they need to debug more
independently. Help students to generalize the strategies that they use by asking them to reflect on what processes were
effective and reframing those processes as a general strategy. They should also learn ways to simplify the debugging
process by making their code more readable with good naming conventions, clear formatting, and relevant comments;
organizing code into functions or other logical chunks where appropriate; and testing small pieces of code as they go. Call
out these practices as facilitating debugging as you help students with their code.
Debugging as problem-solving
In computer science, debugging is framed as a form of problem solving, and students can use a version of the four step
Problem Solving Process as a framework for debugging their programs. Just as in other forms of problem solving, many
students may jump to the “Try” part of the framework and begin making changes to their code before understanding the
nature of the bug itself. Remind them that all parts of the process are important, and that ignoring the other three steps will
actually make debugging more time consuming and difficult in the long run.

Define - Describe the bug


In the context of debugging, defining the problem is describing the bug. This step can be done by anyone using the
program, not just the person who will eventually be debugging it. Students will need to know the following information
before they move on to the next step:

● When does it happen?


● What did you expect the program to do?
● What did it do instead?
● Are there any error messages?

Some bugs will keep the code from running at all, while others will run, but not
correctly, or will run for a while, then stop or suddenly do something unexpected.
All of those things are clues that will help the student find the bug in the next step.

You can encourage students to clearly describe the bugs they find by having them
write up bug reports, such as in their journal or this worksheet. As you foster a
positive culture around debugging, encourage students to write bug reports for
their classmates’ code as well as their own.

Prepare - Hunt for the bug


In most cases, hunting for the bug (the “prepare” step in the debugging process) will take up most of a programmer’s time.
Remind students that it’s natural to take a long time to find a bug, but that there are things that will make their search easier.

1. Why is the bug happening?


Often students focus on what they want the program to do and why they believe their code is correct, rather than
investigating what could be causing the bug. Encourage students to start with the error messages and what is
actually happening when the program is run, and try to connect that with the code that they have written, rather
than explain why their code “should” be working. They can also “trace” their code, by reading it line by line, not
necessarily from top to bottom, but in the order that the computer would interpret it while the program is running.
Using debugging tools such as watchers, breakpoints, or the inspector tool may help them to identify why the code
is running as it is.
2. What changed right before the bug appeared?
If students have been testing their code along the way (as they should!), they can focus on code that they have
recently changed. As they investigate that code, they should follow the logic of their program in the same order
that the code runs, rather than reading the code line by line from top to bottom.
3. How does this code compare to “correct” solutions?
Students should also make use of the various resources available to them, such as working projects, examples in
previous lessons, and code documentation. Have them compare the patterns that they find in the documentation
and exemplars to their own code, differentiating between the programming patterns that should be the same
(loops, counter pattern, HTML syntax) and specifics of their program that will be different (variable names, image
URLs, coordinates).
Try - Change the code
If students believe that they have found the bug, they can go ahead and try to fix it, but in many cases, they may want to
make changes to the code to narrow down their search. Some common strategies include:

1. Commenting out code


By commenting out sections of the program, students can narrow down the part of the program that is causing the
bug. After commenting out large sections of code, or function calls, test whether the bug is eliminated. This
method is especially helpful when students have used good modular programming techniques.
2. Print to the console
Using the console log command can help students to understand whether a conditional has been triggered or keep
track of a quickly changing variable over a period of time.
3. Change the starting values of variables
Changing the starting values of variables can make it easier to reproduce a certain bug. For example, students
may want to change the starting score to 99 to test a bug that only occurs when the score reaches 100. They may
want to set their number of lives to a very high number to allow them to test for longer before losing the game.

In many cases, students will introduce new bugs during the debugging process, especially if they are randomly changing
code as part of a “guess and check” method. Prompt them to explain why they are changing the code, and encourage
them to make small changes and test them often, making it easier to go back if their solution didn’t work.

Reflect - Document what happened


As students make changes and see the effects, they should reflect on and document their experiences. This will help them
to build a better model of how the program constructs work and what debugging strategies are most effective. Students
should consider the following after eliminating a bug from their program:

1. What caused the bug?


The computer had a reason for doing what it did, and students should understand why their code caused the bug.
There may be a rule that they can share with others in the class (“Capitalization matters when it comes to matching
variable names”) or a misconception (“Variables declared inside of an on-event get reset every time the event is
triggered.”) that they can clear up.
2. How did you find the bug?
Have students describe the debugging process that they used, paying special attention to how the type of bug and
any error messages lent themselves to particular debugging strategies. Help them to generalize their strategies so
that they can use them in a variety of situations. (e.g. “I had to capitalize the ‘r’ in my variable” might become “You
double-checked the capitalization and spelling of the variable the program didn’t recognize.”)
3. What in your code made it easier or harder to debug?
Debugging is a great time to reinforce “clean code” practices, such as good naming conventions, the use of
functions, or other ways of “chunking” code into logical sections, commenting, and clear formatting. Point out when
comments or well-named functions and variables make it easier to trace code and find an error. Debugging is also
easier when students have separated out code into logical chunks and functions, which can be commented out
individually.

Writing debuggable code


Various practices will make it easier for students to debug their code. Encourage students to neatly format their code, as
well as make good use of comments and whitespace. Organizing code into logical chunks, using functions, and having
reasonable names for classes, variables, and functions will help them to read and interpret their code as they debug. Point
out times when students’ good programming practices have made it easier for them to debug their own code.
Unit 4 Lesson 4
Name(s)_______________________________________________ Period ______ Date ___________________

Activity Guide - Variables Make


Your Goal: Write the code to make the Photo Liker App. You've
already been given every screen element and have comments
that will help you design your program.

Step 1 - Try using this app


● Try all of the buttons and add a comment to the picture
● Discuss with a Partner
○ What does this app do?
○ What are the inputs?
○ What are the outputs?
○ What's one piece of information that might be
stored in a variable?

Step 2 - Plan
Fill in the information in the table below for each event handler
you'll need to create

Element ID Description of What the Event Handler will Do

Fill in the table below for each variable you'll need to create.
Variable Name What the Variable Stores

Computer Science Principles 1


Unit 4 Lesson 4
Step 3 - Write Your Code
● Write the code for the app, using your plan above and the comments provided in Code Studio to help
● Steps You Can Follow
○ Create all the variables from your table above.
○ Give your variables a starting value using the assignment operator (=)
○ Create blank event handlers (onEvent) for each screen element in your table above
○ Write the code to make the "upButton" work and test it out. If it's working correctly, the "Likes" count
should go up by one every time you click it
○ Write code to make the "downButton" work and test it.
○ Write code to make the "commentButton" work
○ Use your debugging skills to identify unexpected behavior and fix your program
○ Comment your code as you go, explaining what each event handler does
○ Check the Help & Tips tab for ideas about Programming Patterns you can use
● Extension Ideas
○ Set the text in "new_comment" to blank after the comment has been added
○ Add sounds to each button

Step 4 - Submit
Before you submit, check the rubric below to make sure your program meets the requirements of the task.

Category Extensive Evidence Convincing Limited Evidence No Evidence


Evidence

Code: Event onEvents are defined onEvents are defined onEvents are defined onEvents are not
Handlers Created for all the required for most of the for some of the designed for any
buttons. required buttons. buttons. buttons.

Code: Variables Variables are defined Variables are defined One variable is There are no
to store the amount to store the amount present that stores variables which store
of likes and the of likes and the either the amount of the necessary
comments. Variables comments likes or the information for the
are named in a clear comments app to work correctly.
and understandable
way.

Code: Event All necessary Most necessary Some of the None of the
Handlers Written variables are variables are necessary variables necessary variables
updated inside of the updated inside of the are updated inside of are updated inside of
onEvents. onEvents. the onEvents. the onEvents.

Code: Output The screen correctly The screen correctly The screen correctly The screen does not
Information displays the amount displays the amount displays either the display the amount
of likes and the total of likes and the total amount of likes or of likes or the
comments. Sound comments. some amount of comments.
plays when different comments.
buttons are clicked.

Code runs without No errors are At most one error is Some errors are Many errors are
errors. present in the code. present in the code. present in the code. present in the code.

Coding Comments Comments are used Comments are used Comments are used Comments are not
to correctly explain to correctly explain to explain the present
the purpose and the purpose and purpose and function
function of all function of most of some onEvents.
onEvents. onEvents.

Computer Science Principles 2


A Short Introduction to EIPM

What is EIPM?
EIPM is a structured approach to teaching programming in Code.org's CSP Curriculum. It's designed to meet
the needs of diverse learners, encourage collaboration, support independent creation, and clarify the role of
the teacher throughout the learning process. Each letter represents a different type of lesson (E - Explore, I -
Investigate, P - Practice, M - Make) which are taught in sequence for each major programming construct. A
typical programming unit will feature 2 or 3 EIPM sequences, followed by a unit project and a multiple choice
assessment. The visual below shows that structure for Unit 5 - Lists, Loops and Traversals, with each square
being a separate lesson.

Why did you develop EIPM?


The biggest motivator in developing EIPM was direct feedback from students and teachers. While they had
many positive things to say about our programming units, we also heard some consistent concerns. Due to the
way our programming units are designed, students were often working in isolation, teachers lacked clarity on
their role, and classrooms would arrive at the end of the unit lacking the skills to take on major independent
projects. We took this feedback, consulted research and experts in the field of computing education, and
created a pathway for introducing programming concepts that is more collaborative, clarifies the teacher’s role,
and more intentionally prepares students to create programming projects independently.

The Teacher’s Role in the Classroom


The EIPM structure provides more clarity on the
way students are expected to learn in each lesson
and your role in facilitating that learning. In the
Explore and Investigate lessons you will spend
relatively more time leading group activities and
class-wide discussions. In the Practice and Make
lessons you will spend more time circulating the
room to provide support to individuals and small
groups. This predictable transition clarifies your
role in any individual lesson and encourages
students to work with greater independence as
they develop mastery over a new concept. The
graphic to the right shows the gradual transition
from leading students through activities to
supporting students working more independently.
A Summary of Each Lesson Type

Overview Goal

Explore Students explore the new concept Students begin to develop a


through a teacher-led hands-on shared mental model and
group activity. understand the main ideas of the
new concept.
● Typically uses physical
manipulatives
● Teacher leads with support of
slides and activity guides

Students investigate two or three Students become comfortable


Investigate sample programs that use the new reading and modifying programs
concept. that use the new concept.

● Close-reading of working
programs
● Teacher-led discussions
● Tasks to modify apps

Students practice using the new Students gain confidence in


concept through a scaffolded writing and debugging programs
series of programming activities. that use the new concept.
Practice
● Students work independently or
in pairs
● Teacher introduces debugging
practices at the beginning of
the Activity and circulates the
room during the lesson to
provide targeted support.

Students make a target app for Students are able to


which they are given the screen independently decide when and
elements but little to no starter how to use the new concept in
Make code. the context of a larger project.

● Students are provided


high-level steps to break down
the project
● Teacher supports students by
directing them towards notes,
previous work, and debugging
strategies practiced in earlier
lessons.
Variables, Conditionals, and Functions ('24-
'25)
Variables Investigate
Resources
A Short Introduction to EIPM

What is EIPM?
EIPM is a structured approach to teaching programming in Code.org's CSP Curriculum. It's designed to meet
the needs of diverse learners, encourage collaboration, support independent creation, and clarify the role of
the teacher throughout the learning process. Each letter represents a different type of lesson (E - Explore, I -
Investigate, P - Practice, M - Make) which are taught in sequence for each major programming construct. A
typical programming unit will feature 2 or 3 EIPM sequences, followed by a unit project and a multiple choice
assessment. The visual below shows that structure for Unit 5 - Lists, Loops and Traversals, with each square
being a separate lesson.

Why did you develop EIPM?


The biggest motivator in developing EIPM was direct feedback from students and teachers. While they had
many positive things to say about our programming units, we also heard some consistent concerns. Due to the
way our programming units are designed, students were often working in isolation, teachers lacked clarity on
their role, and classrooms would arrive at the end of the unit lacking the skills to take on major independent
projects. We took this feedback, consulted research and experts in the field of computing education, and
created a pathway for introducing programming concepts that is more collaborative, clarifies the teacher’s role,
and more intentionally prepares students to create programming projects independently.

The Teacher’s Role in the Classroom


The EIPM structure provides more clarity on the
way students are expected to learn in each lesson
and your role in facilitating that learning. In the
Explore and Investigate lessons you will spend
relatively more time leading group activities and
class-wide discussions. In the Practice and Make
lessons you will spend more time circulating the
room to provide support to individuals and small
groups. This predictable transition clarifies your
role in any individual lesson and encourages
students to work with greater independence as
they develop mastery over a new concept. The
graphic to the right shows the gradual transition
from leading students through activities to
supporting students working more independently.
A Summary of Each Lesson Type

Overview Goal

Explore Students explore the new concept Students begin to develop a


through a teacher-led hands-on shared mental model and
group activity. understand the main ideas of the
new concept.
● Typically uses physical
manipulatives
● Teacher leads with support of
slides and activity guides

Students investigate two or three Students become comfortable


Investigate sample programs that use the new reading and modifying programs
concept. that use the new concept.

● Close-reading of working
programs
● Teacher-led discussions
● Tasks to modify apps

Students practice using the new Students gain confidence in


concept through a scaffolded writing and debugging programs
series of programming activities. that use the new concept.
Practice
● Students work independently or
in pairs
● Teacher introduces debugging
practices at the beginning of
the Activity and circulates the
room during the lesson to
provide targeted support.

Students make a target app for Students are able to


which they are given the screen independently decide when and
elements but little to no starter how to use the new concept in
Make code. the context of a larger project.

● Students are provided


high-level steps to break down
the project
● Teacher supports students by
directing them towards notes,
previous work, and debugging
strategies practiced in earlier
lessons.
Variables, Conditionals, and Functions ('24-
'25)
Variables Practice
Resources
Guide to Debugging

Introduction to Debugging
Debugging is the process of finding and fixing problems in code. For most
programs, the time spent debugging far outweighs the time spent writing new
code. Whether students or professional engineers, all programmers get bugs,
and debugging is a normal part of the programming process.

Although students may see bugs as inconveniences to be eliminated as soon


as possible, bugs in student programs should be seen as opportunities to
reinforce positive attitudes toward debugging and persistence, identify and
address student misconceptions, and further develop good debugging skills.
Your role as the teacher is to avoid directly debugging for your students, but to
guide students in better taking advantage of these opportunities.

Reinforcing positive attitudes


Finding bugs is the first step toward fixing them. Programmers deliberately test their code in order to uncover any possible
bugs. Celebrate the discovery of new bugs as students report them in the classroom, framing finding a bug as the first step
to fixing it. Model enjoying the interesting or funny behaviors a bug can cause, such as making a sprite move in
unexpected ways, or distorting an image on a web page. Remind students that if programs all worked exactly as they
wanted the first time, programming wouldn’t be as interesting or fun. Encourage students as they get frustrated, reinforcing
the debugging strategies and students’ self-efficacy as they improve their debugging skills, and talk about the bugs that
you get in your own programs, reminding them that everyone gets bugs, even professional software developers.

Identify and address misconceptions


Often a bug occurs because students have misconceptions around how the computer interprets their code. As part of the
debugging process, have students explain their code, line by line, reminding them that the program is really only doing
exactly as it was told. If the program displays an error message, ask the student to connect the message to what is
happening in the code itself. Prompt them with relevant questions about how the associated programming structures (such
as conditionals or loops) work, and refer them back to previous lessons, worked examples, or documentation when
needed. After students have found the bug, ask them to reflect on what they learned about the associated programming
structures and how they could explain it to a friend with a similar bug.

Develop debugging skills


As students get more experience debugging their programs, they will build the skills they need to debug more
independently. Help students to generalize the strategies that they use by asking them to reflect on what processes were
effective and reframing those processes as a general strategy. They should also learn ways to simplify the debugging
process by making their code more readable with good naming conventions, clear formatting, and relevant comments;
organizing code into functions or other logical chunks where appropriate; and testing small pieces of code as they go. Call
out these practices as facilitating debugging as you help students with their code.
Debugging as problem solving
In computer science, debugging is framed as a form of problem solving, and students can use a version of the four step
Problem Solving Process as a framework for debugging their programs. Just as in other forms of problem solving, many
students may jump to the “Try” part of the framework and begin making changes to their code before understanding the
nature of the bug itself. Remind them that all parts of the process are important, and that ignoring the other three steps will
actually make debugging more time consuming and difficult in the long run.

Define - Describe the bug


In the context of debugging, defining the problem is describing the bug. This step can be done by anyone using the
program, not just the person who will eventually be debugging it. Students will need to know the following information
before they move on to the next step:

● When does it happen?


● What did you expect the program to do?
● What did it do instead?
● Are there any error messages?

Some bugs will keep the code from running at all, while others will run, but not
correctly, or will run for a while, then stop or suddenly do something unexpected.
All of those things are clues that will help the student find the bug in the next step.

You can encourage students to clearly describe the bugs they find by having them
write up bug reports, such as in this worksheet. As you foster a positive culture
around debugging, encourage students to write bug reports for their classmates’
code as well as their own.

Prepare - Hunt for the bug


In most cases, hunting for the bug (the “prepare” step in the debugging process) will take up most of a programmer’s time.
Remind students that it’s natural to take a long time to find a bug, but that there are things that will make their search easier.

1. Why is the bug happening?


Often students focus on what they want the program to do and why they believe their code is correct, rather than
investigating what could be causing the bug. Encourage students to start with the error messages and what is
actually happening when the program is run, and try to connect that with the code that they have written, rather
than explain why their code “should” be working. They can also “trace” their code, by reading it line by line, not
necessarily from top to bottom, but in the order that the computer would interpret it while the program is running.
Using debugging tools such as watchers, breakpoints, or the inspector tool may help them to identify why the code
is running as it is.
2. What changed right before the bug appeared?
If students have been testing their code along the way (as they should!), they can focus on code that they have
recently changed. As they investigate that code, they should follow the logic of their program in the same order
that the code runs, rather than reading the code line by line from top to bottom.
3. How does this code compare to “correct” solutions?
Students should also make use of the various resources available to them, such as working projects, examples in
previous lessons, and code documentation. Have them compare the patterns that they find in the documentation
and exemplars to their own code, differentiating between the programming patterns that should be the same
(loops, counter pattern, HTML syntax) and specifics of their program that will be different (variable names, image
URLs, coordinates).
Try - Change the code
If students believe that they have found the bug, they can go ahead and try to fix it, but in many cases they may want to
make changes to the code to narrow down their search. Some common strategies include:

1. Commenting out code


By commenting out sections of the program, students can narrow down the part of the program that is causing the
bug. After commenting out large sections of code, function calls, or html elements, test whether the bug is
eliminated. This method is especially helpful when students have used good modular programming techniques.
2. Print to the console
Using the console log command can help students to understand whether a conditional has been triggered, or
keep track of a quickly changing variable over a period of time.
3. Change the starting values of variables
Changing the starting values of variables can make it easier to reproduce a certain bug. For example, students
may want to change the starting score to 99 to test a bug that only occurs when the score reaches 100. They may
want to set their number of lives to a very high number to allow them to test for longer before losing the game.
4. Amplify small effects
Sometimes bugs have such tiny effects that it’s difficult to investigate them. Amplifying small effects, such as
making elements move further on the screen or giving web page elements a background color to make them more
visible, can make it easier to understand what is happening in a program.

In many cases, students will introduce new bugs during the debugging process, especially if they are randomly changing
code as part of a “guess and check” method. Prompt them to explain why they are changing the code, and encourage
them to make small changes and test them often, making it easier to go back if their solution didn’t work.

Reflect - Document what happened


As students make changes and see the effects, they should reflect and document on their experiences. This will help them
to build a better model of how the program constructs work and what debugging strategies are most effective. Students
should consider the following after they have eliminated a bug from their program:

1. What caused the bug?


The computer had a reason for doing what it did, and students should understand why their code caused the bug
itself. There may be a rule that they can share with others in the class (“There is no closing tag for images”) or a
misconception (“Sprites all get drawn to the screen when `drawSprites` is called, not when they are updated.”) that
they can clear up.
2. How did you find the bug?
Have students describe the debugging process that they used, paying special attention to how the type of bug and
any error messages lent themselves to particular debugging strategies. Help them to generalize their strategies so
that they can use them in a variety of situations. (e.g. “I had to capitalize the ‘r’ in my variable” might become “You
double checked the capitalization and spelling of the variable the program didn’t recognize.”)
3. What in your code made it easier or harder to debug?
Debugging is a great time to reinforce “clean code” practices, such as good naming conventions, use of functions
or other ways of “chunking” code into logical sections, commenting, and clear formatting. Point out when
comments or well named functions and variables make it easier to trace code and find an error. Debugging is also
easier when students have separated out code into logical chunks and functions, which can be commented out
individually.

Writing debuggable code


Various practices will make it easier for students to debug their code. Encourage students to neatly format their code, as
well as make good use of comments and whitespace. Organizing code into logical chunks, using functions, and having
reasonable names for classes, variables, and functions will help them to read and interpret their code as they debug. Point
out times when students’ good programming practices have made it easier for them to debug their own code.
A Short Introduction to EIPM

What is EIPM?
EIPM is a structured approach to teaching programming in Code.org's CSP Curriculum. It's designed to meet
the needs of diverse learners, encourage collaboration, support independent creation, and clarify the role of
the teacher throughout the learning process. Each letter represents a different type of lesson (E - Explore, I -
Investigate, P - Practice, M - Make) which are taught in sequence for each major programming construct. A
typical programming unit will feature 2 or 3 EIPM sequences, followed by a unit project and a multiple choice
assessment. The visual below shows that structure for Unit 5 - Lists, Loops and Traversals, with each square
being a separate lesson.

Why did you develop EIPM?


The biggest motivator in developing EIPM was direct feedback from students and teachers. While they had
many positive things to say about our programming units, we also heard some consistent concerns. Due to the
way our programming units are designed, students were often working in isolation, teachers lacked clarity on
their role, and classrooms would arrive at the end of the unit lacking the skills to take on major independent
projects. We took this feedback, consulted research and experts in the field of computing education, and
created a pathway for introducing programming concepts that is more collaborative, clarifies the teacher’s role,
and more intentionally prepares students to create programming projects independently.

The Teacher’s Role in the Classroom


The EIPM structure provides more clarity on the
way students are expected to learn in each lesson
and your role in facilitating that learning. In the
Explore and Investigate lessons you will spend
relatively more time leading group activities and
class-wide discussions. In the Practice and Make
lessons you will spend more time circulating the
room to provide support to individuals and small
groups. This predictable transition clarifies your
role in any individual lesson and encourages
students to work with greater independence as
they develop mastery over a new concept. The
graphic to the right shows the gradual transition
from leading students through activities to
supporting students working more independently.
A Summary of Each Lesson Type

Overview Goal

Explore Students explore the new concept Students begin to develop a


through a teacher-led hands-on shared mental model and
group activity. understand the main ideas of the
new concept.
● Typically uses physical
manipulatives
● Teacher leads with support of
slides and activity guides

Students investigate two or three Students become comfortable


Investigate sample programs that use the new reading and modifying programs
concept. that use the new concept.

● Close-reading of working
programs
● Teacher-led discussions
● Tasks to modify apps

Students practice using the new Students gain confidence in


concept through a scaffolded writing and debugging programs
series of programming activities. that use the new concept.
Practice
● Students work independently or
in pairs
● Teacher introduces debugging
practices at the beginning of
the Activity and circulates the
room during the lesson to
provide targeted support.

Students make a target app for Students are able to


which they are given the screen independently decide when and
elements but little to no starter how to use the new concept in
Make code. the context of a larger project.

● Students are provided


high-level steps to break down
the project
● Teacher supports students by
directing them towards notes,
previous work, and debugging
strategies practiced in earlier
lessons.
Variables, Conditionals, and Functions ('24-
'25)
Variables Make
Resources
Unit 4 Lesson 4
Name(s)_______________________________________________ Period ______ Date ___________________

Activity Guide - Variables Make


Your Goal: Write the code to make the Photo Liker App. You've
already been given every screen element and have comments
that will help you design your program.

Step 1 - Try using this app


● Try all of the buttons and add a comment to the picture
● Discuss with a Partner
○ What does this app do?
○ What are the inputs?
○ What are the outputs?
○ What's one piece of information that might be
stored in a variable?

Step 2 - Plan
Fill in the information in the table below for each event handler
you'll need to create

Element ID Description of What the Event Handler will Do

Fill in the table below for each variable you'll need to create.
Variable Name What the Variable Stores

Computer Science Principles 1


Unit 4 Lesson 4
Step 3 - Write Your Code
● Write the code for the app, using your plan above and the comments provided in Code Studio to help
● Steps You Can Follow
○ Create all the variables from your table above.
○ Give your variables a starting value using the assignment operator (=)
○ Create blank event handlers (onEvent) for each screen element in your table above
○ Write the code to make the "upButton" work and test it out. If it's working correctly, the "Likes" count
should go up by one every time you click it
○ Write code to make the "downButton" work and test it.
○ Write code to make the "commentButton" work
○ Use your debugging skills to identify unexpected behavior and fix your program
○ Comment your code as you go, explaining what each event handler does
○ Check the Help & Tips tab for ideas about Programming Patterns you can use
● Extension Ideas
○ Set the text in "new_comment" to blank after the comment has been added
○ Add sounds to each button

Step 4 - Submit
Before you submit, check the rubric below to make sure your program meets the requirements of the task.

Category Extensive Evidence Convincing Limited Evidence No Evidence


Evidence

Code: Event onEvents are defined onEvents are defined onEvents are defined onEvents are not
Handlers Created for all the required for most of the for some of the designed for any
buttons. required buttons. buttons. buttons.

Code: Variables Variables are defined Variables are defined One variable is There are no
to store the amount to store the amount present that stores variables which store
of likes and the of likes and the either the amount of the necessary
comments. Variables comments likes or the information for the
are named in a clear comments app to work correctly.
and understandable
way.

Code: Event All necessary Most necessary Some of the None of the
Handlers Written variables are variables are necessary variables necessary variables
updated inside of the updated inside of the are updated inside of are updated inside of
onEvents. onEvents. the onEvents. the onEvents.

Code: Output The screen correctly The screen correctly The screen correctly The screen does not
Information displays the amount displays the amount displays either the display the amount
of likes and the total of likes and the total amount of likes or of likes or the
comments. Sound comments. some amount of comments.
plays when different comments.
buttons are clicked.

Code runs without No errors are At most one error is Some errors are Many errors are
errors. present in the code. present in the code. present in the code. present in the code.

Coding Comments Comments are used Comments are used Comments are used Comments are not
to correctly explain to correctly explain to explain the present
the purpose and the purpose and purpose and function
function of all function of most of some onEvents.
onEvents. onEvents.

Computer Science Principles 2


Variables, Conditionals, and Functions ('24-
'25)
Conditionals Practice
Resources
Guide to Debugging

Introduction to Debugging
Debugging is the process of finding and fixing problems in code. For most
programs, the time spent debugging far outweighs the time spent writing new
code. Whether students or professional engineers, all programmers get bugs,
and debugging is a normal part of the programming process.

Although students may see bugs as inconveniences to be eliminated as soon


as possible, bugs in student programs should be seen as opportunities to
reinforce positive attitudes toward debugging and persistence, identify and
address student misconceptions, and further develop good debugging skills.
Your role as the teacher is to avoid directly debugging for your students, but to
guide students in better taking advantage of these opportunities.

Reinforcing positive attitudes


Finding bugs is the first step toward fixing them. Programmers deliberately test their code in order to uncover any possible
bugs. Celebrate the discovery of new bugs as students report them in the classroom, framing finding a bug as the first step
to fixing it. Model enjoying the interesting or funny behaviors a bug can cause, such as making a sprite move in
unexpected ways, or distorting an image on a web page. Remind students that if programs all worked exactly as they
wanted the first time, programming wouldn’t be as interesting or fun. Encourage students as they get frustrated, reinforcing
the debugging strategies and students’ self-efficacy as they improve their debugging skills, and talk about the bugs that
you get in your own programs, reminding them that everyone gets bugs, even professional software developers.

Identify and address misconceptions


Often a bug occurs because students have misconceptions around how the computer interprets their code. As part of the
debugging process, have students explain their code, line by line, reminding them that the program is really only doing
exactly as it was told. If the program displays an error message, ask the student to connect the message to what is
happening in the code itself. Prompt them with relevant questions about how the associated programming structures (such
as conditionals or loops) work, and refer them back to previous lessons, worked examples, or documentation when
needed. After students have found the bug, ask them to reflect on what they learned about the associated programming
structures and how they could explain it to a friend with a similar bug.

Develop debugging skills


As students get more experience debugging their programs, they will build the skills they need to debug more
independently. Help students to generalize the strategies that they use by asking them to reflect on what processes were
effective and reframing those processes as a general strategy. They should also learn ways to simplify the debugging
process by making their code more readable with good naming conventions, clear formatting, and relevant comments;
organizing code into functions or other logical chunks where appropriate; and testing small pieces of code as they go. Call
out these practices as facilitating debugging as you help students with their code.
Debugging as problem-solving
In computer science, debugging is framed as a form of problem solving, and students can use a version of the four step
Problem Solving Process as a framework for debugging their programs. Just as in other forms of problem solving, many
students may jump to the “Try” part of the framework and begin making changes to their code before understanding the
nature of the bug itself. Remind them that all parts of the process are important, and that ignoring the other three steps will
actually make debugging more time consuming and difficult in the long run.

Define - Describe the bug


In the context of debugging, defining the problem is describing the bug. This step can be done by anyone using the
program, not just the person who will eventually be debugging it. Students will need to know the following information
before they move on to the next step:

● When does it happen?


● What did you expect the program to do?
● What did it do instead?
● Are there any error messages?

Some bugs will keep the code from running at all, while others will run, but not
correctly, or will run for a while, then stop or suddenly do something unexpected.
All of those things are clues that will help the student find the bug in the next step.

You can encourage students to clearly describe the bugs they find by having them
write up bug reports, such as in their journal or this worksheet. As you foster a
positive culture around debugging, encourage students to write bug reports for
their classmates’ code as well as their own.

Prepare - Hunt for the bug


In most cases, hunting for the bug (the “prepare” step in the debugging process) will take up most of a programmer’s time.
Remind students that it’s natural to take a long time to find a bug, but that there are things that will make their search easier.

1. Why is the bug happening?


Often students focus on what they want the program to do and why they believe their code is correct, rather than
investigating what could be causing the bug. Encourage students to start with the error messages and what is
actually happening when the program is run, and try to connect that with the code that they have written, rather
than explain why their code “should” be working. They can also “trace” their code, by reading it line by line, not
necessarily from top to bottom, but in the order that the computer would interpret it while the program is running.
Using debugging tools such as watchers, breakpoints, or the inspector tool may help them to identify why the code
is running as it is.
2. What changed right before the bug appeared?
If students have been testing their code along the way (as they should!), they can focus on code that they have
recently changed. As they investigate that code, they should follow the logic of their program in the same order
that the code runs, rather than reading the code line by line from top to bottom.
3. How does this code compare to “correct” solutions?
Students should also make use of the various resources available to them, such as working projects, examples in
previous lessons, and code documentation. Have them compare the patterns that they find in the documentation
and exemplars to their own code, differentiating between the programming patterns that should be the same
(loops, counter pattern, HTML syntax) and specifics of their program that will be different (variable names, image
URLs, coordinates).
Try - Change the code
If students believe that they have found the bug, they can go ahead and try to fix it, but in many cases, they may want to
make changes to the code to narrow down their search. Some common strategies include:

1. Commenting out code


By commenting out sections of the program, students can narrow down the part of the program that is causing the
bug. After commenting out large sections of code, or function calls, test whether the bug is eliminated. This
method is especially helpful when students have used good modular programming techniques.
2. Print to the console
Using the console log command can help students to understand whether a conditional has been triggered or keep
track of a quickly changing variable over a period of time.
3. Change the starting values of variables
Changing the starting values of variables can make it easier to reproduce a certain bug. For example, students
may want to change the starting score to 99 to test a bug that only occurs when the score reaches 100. They may
want to set their number of lives to a very high number to allow them to test for longer before losing the game.

In many cases, students will introduce new bugs during the debugging process, especially if they are randomly changing
code as part of a “guess and check” method. Prompt them to explain why they are changing the code, and encourage
them to make small changes and test them often, making it easier to go back if their solution didn’t work.

Reflect - Document what happened


As students make changes and see the effects, they should reflect on and document their experiences. This will help them
to build a better model of how the program constructs work and what debugging strategies are most effective. Students
should consider the following after eliminating a bug from their program:

1. What caused the bug?


The computer had a reason for doing what it did, and students should understand why their code caused the bug.
There may be a rule that they can share with others in the class (“Capitalization matters when it comes to matching
variable names”) or a misconception (“Variables declared inside of an on-event get reset every time the event is
triggered.”) that they can clear up.
2. How did you find the bug?
Have students describe the debugging process that they used, paying special attention to how the type of bug and
any error messages lent themselves to particular debugging strategies. Help them to generalize their strategies so
that they can use them in a variety of situations. (e.g. “I had to capitalize the ‘r’ in my variable” might become “You
double-checked the capitalization and spelling of the variable the program didn’t recognize.”)
3. What in your code made it easier or harder to debug?
Debugging is a great time to reinforce “clean code” practices, such as good naming conventions, the use of
functions, or other ways of “chunking” code into logical sections, commenting, and clear formatting. Point out when
comments or well-named functions and variables make it easier to trace code and find an error. Debugging is also
easier when students have separated out code into logical chunks and functions, which can be commented out
individually.

Writing debuggable code


Various practices will make it easier for students to debug their code. Encourage students to neatly format their code, as
well as make good use of comments and whitespace. Organizing code into logical chunks, using functions, and having
reasonable names for classes, variables, and functions will help them to read and interpret their code as they debug. Point
out times when students’ good programming practices have made it easier for them to debug their own code.
Variables, Conditionals, and Functions ('24-
'25)
Conditionals Make
Resources
Unit 4 Lesson 8
Name(s)_______________________________________________ Period ______ Date ___________________

Activity Guide - Conditionals Make


Step 1 - Try the app
Try making tickets for different combinations of inputs.
● Make a ticket for a weekend.
● Make a ticket for a weekday (Monday - Friday) and someone 18 or
younger.
● Try the discount code "FREEFRIDAY" on a Friday.

Discuss with a Partner


● What variables would you need to program this app?
● Where does this app use conditionals (if-statements)?

Step 2 - Plan
Variables: Fill in the table below for each variable you'll need to create.
Variable Name What the Variable Stores

Conditionals: Draw a flowchart that follows the rules below. There's more than one way to do it. Use the table to make
sure that your flowchart works for different combinations of age, day, and discount code.

● On the weekends ("Saturday" and "Sunday") everyone pays full price of $10
● On weekdays (Monday through Friday) if you are 18 years or younger you pay $5.
● If you use the discount code "FREEFRIDAY" on a Friday you get in for $0. No other discount codes will work
and the code only works on Fridays.

Test Cases

Age Day Discount Code Price

18 Monday none $5

18 Saturday none $10

50 Monday none $10

50 Saturday none $10

18 Tuesday FREEFRIDAY $5

50 Friday FREEFRIDAY $0

18 Friday FREE $5

50 Friday FREE $10

Computer Science Principles 1


Unit 4 Lesson 8
Step 3 - Write Your Code
● Write the code for the app, using your plan above and the comments provided in Code Studio to help
● Step You Can Follow
○ Create all the variables from your table above.
○ Give your variables a starting value using the assignment operator (=)
○ Create an event handler (onEvent) for the "calculate_button"
○ Inside the event handler start writing code for your conditional using your flowchart
○ Test your code as you go using the table below. At the end it should work for every combination of
outputs in the table on the first page.
○ Use your debugging skills to identify unexpected behavior and fix your program
○ Comment your code as you go, explaining what each event handler does
● Check the Help & Tips tab for ideas about Programming Patterns you can use
● Extension Ideas
○ Add another discount code for a different day of the week or age range
○ Make guests 65 and older always pay $5 unless they use a discount code

Step 4 - Submit
Before you submit, check the rubric below to make sure your program meets the requirements of the task.

Category Extensive Evidence Convincing Limited Evidence No Evidence


Evidence

Input onEvents are onEvents are onEvents are onEvents are not
created for all the created for most of created for some of created for any
required inputs. the inputs. the inputs. inputs.

Storage: Variables Variables are created Most information is Some information is There are no
and appropriately stored in a variable stored in a variable variables which store
used for all pieces of and appropriately and appropriately the necessary
information used in updated throughout updated throughout information for the
the app. the app. the app. app to work correctly.

Processing: The code correctly The code correctly The code correctly The code does not
Conditional Logic determines the price determines the price determines the price correctly determine
for all combinations for most but not all for some but not all the price for any
of inputs (age, price, combinations of combinations of combination of inputs
discount code). inputs (age, price, inputs (age, price, (age, price, discount
discount code). discount code). code).

Code: Output The screen correctly The screen displays The screen displays The screen does not
displays the day, most but not all some but not all correctly display any
age, and price of the information correctly information correctly information in the
ticket. in the ticket. in the ticket. ticket.

Code runs without No errors are On or two errors are Three or four errors More than four errors
errors. present in the present in the are present in the are present in the
required code. required code. required code. required code.

Coding Comments Comments are used Comments are used Comments are used Comments are not
to correctly explain to explain the to explain the present.
the purpose and purpose and function purpose and function
function of all of most onEvents of some onEvents
onEvents and and conditional logic. and conditional logic.
conditional logic.

Computer Science Principles 2


Variables, Conditionals, and Functions ('24-
'25)
Functions Explore / Investigate
Resources
Unit 4 Lesson 9
Name(s)_______________________________________________ Period ______ Date ___________________

Activity Guide - Song Lyrics

Style 1 Style 2

00 Feeling my way through the darkness 00 Feeling my way through the darkness
01 Guided by a beating heart 01 Guided by a beating heart
02 I can't tell where the journey will end 02 I can't tell where the journey will end
03 But I know where to start 03 But I know where to start
04 04
05 They tell me I'm too young to understand 05 They tell me I'm too young to understand
06 They say I'm caught up in a dream 06 They say I'm caught up in a dream
07 Well life will pass me by if I don't open up my eyes 07 Well life will pass me by if I don't open up my eyes
08 Well that's fine by me 08 Well that's fine by me
09 09
10 So wake me up when it's all over 10 Sing Chorus (the lyrics are below)
11 When I'm wiser and I'm older 11
12 All this time I was finding myself 12 Sing Chorus (the lyrics are below)
13 And I didn't know I was lost 13
14 14 I tried carrying the weight of the world
15 So wake me up when it's all over 15 But I only have two hands
16 When I'm wiser and I'm older 16 I hope I get the chance to travel the world
17 All this time I was finding myself 17 But I don't have any plans
18 And I didn't know I was lost 18
19 19 I wish that I could stay forever this young
20 I tried carrying the weight of the world 20 Not afraid to close my eyes
21 But I only have two hands 21 Life's a game made for everyone
22 I hope I get the chance to travel the world 22 And love is the prize
23 But I don't have any plans 23
24 I wish that I could stay forever this young 24 Sing Chorus (the lyrics are below)
25 Not afraid to close my eyes 25
26 Life's a game made for everyone 26 Sing Chorus (the lyrics are below)
27 And love is the prize 27
28 28 I didn't know I was lost
29 So wake me up when it's all over 29 I didn't know I was lost
30 When I'm wiser and I'm older 30 I didn't know I was lost
31 All this time I was finding myself 31 I didn't know I was lost
32 And I didn't know I was lost 32
33 33 Sing Chorus (the lyrics are below)
34 So wake me up when it's all over 34
35 When I'm wiser and I'm older 35 Chorus Lyrics:
36 All this time I was finding myself 36 So wake me up when it's all over
37 And I didn't know I was lost 37 When I'm wiser and I'm older
38 38 All this time I was finding myself
39 I didn't know I was lost 39 And I didn't know I was lost
40 I didn't know I was lost
41 I didn't know I was lost
42 I didn't know I was lost
43
44 So wake me up when it's all over
45 When I'm wiser and I'm older
46 All this time I was finding myself
47 And I didn't know I was lost

1
Variables, Conditionals, and Functions ('24-
'25)
Functions Make
Resources
Unit 4 Lesson 11
Name(s)_______________________________________________ Period ______ Date ___________________

Activity Guide - Functions Make


Step 1 - Try the app
● Try many of the different options.
● Pay attention to what is happening on the screen
when you move the slider or choose an item from the
dropdown.
● When does the screen update?
● What happens if you choose lavender and Lucida
Sans from the dropdowns? Try choosing lightgreen
and moving the slider until you receive feedback.

Discuss with a Partner


● What does this app do?
● What are the inputs?
● What are the outputs?
● How could a function be used in this app?

Step 2 - Plan

Variables: Fill in the table below for each variable you'll need to create.
Variable Name What the Variable Stores

color the background color the user selects

fontFamily

Conditionals: An if-else-if statement is used to check if certain options have been selected. Set up the conditional
below using the variables you created above.
● Note: You can be creative here! Choose your own combinations and feedback messages.

if (color == _______________ && fontFamily == _______________ ){


setText("feedbackOutput", ______________________________);
} else if ( _______________ == _______________ && _______________ == _______________ ){
setText("feedbackOutput", ______________________________);
} else {
setText("feedbackOutput", ______________________________);
}

Computer Science Principles 1


Unit 4 Lesson 11

Functions: Consider what should be included in a function that updates the screen. Write out your plan below.
Things to think about:
● What elements on the screen need to be updated using the variables above?
● Does the conditional above belong in the function? Why or why not?
● When will the function be called?
Review the updateScreen() Pattern to help you plan
your function.

Inputs: What are the inputs for the app? These will all be turned into onEvents.
Input Action Result

"quoteInput" input The text on the screen appears, one character at a time as it's typed.

"fontFamilyInput" change

Computer Science Principles 2


Unit 4 Lesson 11
Step 3 - Write Your Code
● Write the code for the app, using your plan above and the comments provided in Code Studio to help
● Step You Can Follow
○ Create all the variables from your table above.
○ Give your variables a starting value using the assignment operator (=)
○ Create a conditional that checks if various options are selected.
○ Create a function that updates the screen.
○ Create event handlers (onEvent) for the inputs in your table above
○ Use your debugging skills to identify unexpected behavior and fix your program
○ Comment your code as you go, explaining what each event handler and function does
● Extension Ideas
○ Create a dropdown with image names and decorate your quote!

Step 4 - Submit
Before you submit, check the rubric below to make sure your program meets the requirements of the task.

Category Extensive Evidence Convincing Limited Evidence No Evidence


Evidence

Input onEvents are onEvents are onEvents are onEvents are not
created for all the created for most of created for some of created for any
required inputs. the inputs. the inputs. inputs.

Storage: Variables Variables are created Most information is Some information is There are no
and appropriately stored in a variable stored in a variable variables which store
used for all pieces of and appropriately and appropriately the necessary
information used in updated throughout updated throughout information for the
the app. the app. the app. app to work correctly.

Code: Conditionals An if-else-if An if-else-if An if-else statement No conditional is


statement is used statement is used or an if statement is present.
which correctly that partially checks used that checks if
checks if certain if certain options one option has been
options have been have been selected selected.
selected and and displays
displays feedback. feedback.

Code: Functions A function is used A function is used A function is used There is no function
which correctly which correctly which updates some which updates the
updates all output updates most of the of the output screen.
elements. The output elements. The elements or the
function is called in function is called in function is only
all onEvents. all onEvents. called in some
onEvents.

Code runs without No errors are One or two errors Three or four errors More than four errors
errors. present in the are present in the are present in the are present in the
required code. required code. required code. required code.

Coding Comments Comments are used Comments are used Comments are used Comments are not
to correctly explain to explain the to explain the present.
the purpose and purpose and function purpose and function
function of all of most onEvents of some onEvents
onEvents and and functions. and functions.
functions.

Computer Science Principles 3


Variables, Conditionals, and Functions ('24-
'25)
Project - Decision Maker App
Resources
Name(s)_______________________________________________ Period ______ Date ___________________

U4 Practice PT Rubric

Rubric - Checklist

Category Checklist Item

Planning guide is fully completed.


App Development Planning Guide

Video shows the program running, including input, program


Video functionality, and output.

Response accurately describes the purpose, functionality, and


Written Response 1 inputs/outputs of the app.

Response clearly describes an idea or recommendation


Written Response 2 provided by a partner/peer and how it improved the app.

The User Interface is easy to navigate, it's clear how the app is
User Interface designed to be used, and all text is readable.

No warnings or error messages appear when the app is run.


Code: Warnings & Error Messages

At least one number and one string are each stored in a variable
Code: Variables and used to make a decision.

A function is used to update the screen and is called at least two


Code: Function times in the program.

A conditional is used inside of the function to make a decision


based on information stored in variables, correctly using a logical
Code: Conditional operator in the Boolean expression, and displaying the decision
on the screen with at least three different responses.

The update screen function has a comment which clearly


Code: Comments explains its purpose and functionality.
Rubric

Category Convincing Evidence Approaching Evidence Limited Evidence No Evidence

App Development Planning guide is fully Planning guide is mostly Planning guide is Planning guide is not
Planning Guide: completed. completed. somewhat complete. complete.

Video Video shows the program Video shows the program Video shows the program No video was made.
running including input, running and two of the running and one of the
program functionality, and following: input, program following: input, program
output. functionality, and output. functionality, or output.

Written Response 1: Response accurately Response describes the Response partially Response does not
describes the purpose, purpose and functionality, describes the purpose and describe the purpose,
functionality, and or the inputs/outputs of functionality, or the functionality, and
inputs/outputs of the app. the app. inputs/outputs of the app. inputs/outputs of the app.

Written Response 2: Response clearly describes Response describes an Response describes an Response does not
an idea or recommendation idea or recommendation idea or recommendation describe an idea or
provided by a partner / peer provided by a partner / provided by a partner, but recommendation provided
and how it improved the app. peer and how it improved does not explain how it by a partner.
the app, lacking clarity. improved the app.

User Interface: The User Interface is easy to The User Interface is The User Interface is The User Interface is
navigate and it’s clear how mostly easy to navigate lacking in some readability difficult to navigate and it’s
the app is designed to be and it’s clear how the app or it’s not clear how to use not clear how the app is
used. All text is readable. is designed to be used. All the app. designed to be used. Text
text is readable. is unreadable.

Code: Warnings & Error No warnings or error A few warnings or error Many warnings or error The app does not run at
Messages messages appear when the messages appear when messages appear when all.
app is run. the app is run.. the app is run.

Code: Variables At least one number and One data type (numbers One variable stores either No variables are set up or
one String are each stored in or Strings) is stored in at a number or String and is used to make a decision.
a variable and used to make least two variables and used to make a decision.
a decision. used to make a decision.

Code: Function A function is used to update A function is used to A function is created to A function was not created
the screen. The function is update the screen. The update the screen but is to update the screen.
called at least two times in function is called one time not called in the program.
the program. in the program.

Code: Conditional A conditional is used inside A conditional is used A conditional is created No conditionals are
of the function to make a inside of the function to inside of the function, but present in the function.
decision based on make a decision based on does not use information
information stored in information stored in stored in variables to
variables. The conditional variables. The conditional make a decision or display
correctly uses a logical does not correctly use a it on the screen.
operator (&&, ||, or !) in the logical operator (&&, ||, or
Boolean expression. The !) in the Boolean
decision is displayed on the expression. The decision
screen. There are at least is displayed on the
three different responses screen. There are at least
that could be displayed. two different responses
that could be displayed.

Code: Comments The update screen function The update screen A comment is present, but No comments are present.
has a comment which clearly function has a comment it does not clearly explain
explains its purpose and which clearly explains its anything about the
functionality. purpose or functionality. function.

2
Variables, Conditionals, and Functions ('24-
'25)
Conditionals Practice (Alternative)
Resources
Guide to Debugging

Introduction to Debugging
Debugging is the process of finding and fixing problems in code. For most
programs, the time spent debugging far outweighs the time spent writing new
code. Whether students or professional engineers, all programmers get bugs,
and debugging is a normal part of the programming process.

Although students may see bugs as inconveniences to be eliminated as soon


as possible, bugs in student programs should be seen as opportunities to
reinforce positive attitudes toward debugging and persistence, identify and
address student misconceptions, and further develop good debugging skills.
Your role as the teacher is to avoid directly debugging for your students, but to
guide students in better taking advantage of these opportunities.

Reinforcing positive attitudes


Finding bugs is the first step toward fixing them. Programmers deliberately test their code in order to uncover any possible
bugs. Celebrate the discovery of new bugs as students report them in the classroom, framing finding a bug as the first step
to fixing it. Model enjoying the interesting or funny behaviors a bug can cause, such as making a sprite move in
unexpected ways, or distorting an image on a web page. Remind students that if programs all worked exactly as they
wanted the first time, programming wouldn’t be as interesting or fun. Encourage students as they get frustrated, reinforcing
the debugging strategies and students’ self-efficacy as they improve their debugging skills, and talk about the bugs that
you get in your own programs, reminding them that everyone gets bugs, even professional software developers.

Identify and address misconceptions


Often a bug occurs because students have misconceptions around how the computer interprets their code. As part of the
debugging process, have students explain their code, line by line, reminding them that the program is really only doing
exactly as it was told. If the program displays an error message, ask the student to connect the message to what is
happening in the code itself. Prompt them with relevant questions about how the associated programming structures (such
as conditionals or loops) work, and refer them back to previous lessons, worked examples, or documentation when
needed. After students have found the bug, ask them to reflect on what they learned about the associated programming
structures and how they could explain it to a friend with a similar bug.

Develop debugging skills


As students get more experience debugging their programs, they will build the skills they need to debug more
independently. Help students to generalize the strategies that they use by asking them to reflect on what processes were
effective and reframing those processes as a general strategy. They should also learn ways to simplify the debugging
process by making their code more readable with good naming conventions, clear formatting, and relevant comments;
organizing code into functions or other logical chunks where appropriate; and testing small pieces of code as they go. Call
out these practices as facilitating debugging as you help students with their code.
Debugging as problem solving
In computer science, debugging is framed as a form of problem solving, and students can use a version of the four step
Problem Solving Process as a framework for debugging their programs. Just as in other forms of problem solving, many
students may jump to the “Try” part of the framework and begin making changes to their code before understanding the
nature of the bug itself. Remind them that all parts of the process are important, and that ignoring the other three steps will
actually make debugging more time consuming and difficult in the long run.

Define - Describe the bug


In the context of debugging, defining the problem is describing the bug. This step can be done by anyone using the
program, not just the person who will eventually be debugging it. Students will need to know the following information
before they move on to the next step:

● When does it happen?


● What did you expect the program to do?
● What did it do instead?
● Are there any error messages?

Some bugs will keep the code from running at all, while others will run, but not
correctly, or will run for a while, then stop or suddenly do something unexpected.
All of those things are clues that will help the student find the bug in the next step.

You can encourage students to clearly describe the bugs they find by having them
write up bug reports, such as in this worksheet. As you foster a positive culture
around debugging, encourage students to write bug reports for their classmates’
code as well as their own.

Prepare - Hunt for the bug


In most cases, hunting for the bug (the “prepare” step in the debugging process) will take up most of a programmer’s time.
Remind students that it’s natural to take a long time to find a bug, but that there are things that will make their search easier.

1. Why is the bug happening?


Often students focus on what they want the program to do and why they believe their code is correct, rather than
investigating what could be causing the bug. Encourage students to start with the error messages and what is
actually happening when the program is run, and try to connect that with the code that they have written, rather
than explain why their code “should” be working. They can also “trace” their code, by reading it line by line, not
necessarily from top to bottom, but in the order that the computer would interpret it while the program is running.
Using debugging tools such as watchers, breakpoints, or the inspector tool may help them to identify why the code
is running as it is.
2. What changed right before the bug appeared?
If students have been testing their code along the way (as they should!), they can focus on code that they have
recently changed. As they investigate that code, they should follow the logic of their program in the same order
that the code runs, rather than reading the code line by line from top to bottom.
3. How does this code compare to “correct” solutions?
Students should also make use of the various resources available to them, such as working projects, examples in
previous lessons, and code documentation. Have them compare the patterns that they find in the documentation
and exemplars to their own code, differentiating between the programming patterns that should be the same
(loops, counter pattern, HTML syntax) and specifics of their program that will be different (variable names, image
URLs, coordinates).
Try - Change the code
If students believe that they have found the bug, they can go ahead and try to fix it, but in many cases they may want to
make changes to the code to narrow down their search. Some common strategies include:

1. Commenting out code


By commenting out sections of the program, students can narrow down the part of the program that is causing the
bug. After commenting out large sections of code, function calls, or html elements, test whether the bug is
eliminated. This method is especially helpful when students have used good modular programming techniques.
2. Print to the console
Using the console log command can help students to understand whether a conditional has been triggered, or
keep track of a quickly changing variable over a period of time.
3. Change the starting values of variables
Changing the starting values of variables can make it easier to reproduce a certain bug. For example, students
may want to change the starting score to 99 to test a bug that only occurs when the score reaches 100. They may
want to set their number of lives to a very high number to allow them to test for longer before losing the game.
4. Amplify small effects
Sometimes bugs have such tiny effects that it’s difficult to investigate them. Amplifying small effects, such as
making elements move further on the screen or giving web page elements a background color to make them more
visible, can make it easier to understand what is happening in a program.

In many cases, students will introduce new bugs during the debugging process, especially if they are randomly changing
code as part of a “guess and check” method. Prompt them to explain why they are changing the code, and encourage
them to make small changes and test them often, making it easier to go back if their solution didn’t work.

Reflect - Document what happened


As students make changes and see the effects, they should reflect and document on their experiences. This will help them
to build a better model of how the program constructs work and what debugging strategies are most effective. Students
should consider the following after they have eliminated a bug from their program:

1. What caused the bug?


The computer had a reason for doing what it did, and students should understand why their code caused the bug
itself. There may be a rule that they can share with others in the class (“There is no closing tag for images”) or a
misconception (“Sprites all get drawn to the screen when `drawSprites` is called, not when they are updated.”) that
they can clear up.
2. How did you find the bug?
Have students describe the debugging process that they used, paying special attention to how the type of bug and
any error messages lent themselves to particular debugging strategies. Help them to generalize their strategies so
that they can use them in a variety of situations. (e.g. “I had to capitalize the ‘r’ in my variable” might become “You
double checked the capitalization and spelling of the variable the program didn’t recognize.”)
3. What in your code made it easier or harder to debug?
Debugging is a great time to reinforce “clean code” practices, such as good naming conventions, use of functions
or other ways of “chunking” code into logical sections, commenting, and clear formatting. Point out when
comments or well named functions and variables make it easier to trace code and find an error. Debugging is also
easier when students have separated out code into logical chunks and functions, which can be commented out
individually.

Writing debuggable code


Various practices will make it easier for students to debug their code. Encourage students to neatly format their code, as
well as make good use of comments and whitespace. Organizing code into logical chunks, using functions, and having
reasonable names for classes, variables, and functions will help them to read and interpret their code as they debug. Point
out times when students’ good programming practices have made it easier for them to debug their own code.

You might also like