Conditions
- Terminology and concepts to look out for: event · condition · action
- Relevance to me: Yesterday you tested Code Coach's rules. Today you look at how a rule says what a program does in one particular case, which is also the way Java's if statements work.
- Board Question: You press Ask in the Code Coach panel without picking a line. What should the bench do, and what should it not do? Write each as one sentence.
Open the discussion form on the right and answer Section 1 from your first reading.
Events, Conditions and Actions
This section explains how a program's behavior is written as sentences, and the three parts that each of those sentences needs.
Events and Conditions
An event is something that happens that a program can respond to. A click on a button, a key press and a web page finishing loading are all events, according to Mozilla's guide for web developers. A request to a server that finishes with its answer back is also an event, and a page can respond to it. For example, pressing Check row on Bench Basics is an event, because at one moment the button is pressed. The phrase "the box is empty" does not describe an event, because nothing happened, so it describes a condition.
A condition is a check that is either true or false at that moment. The box is empty, the row is right and the input is Java are all conditions. Each one has only two possible answers at a given moment. The phrase "you press Check row" does not describe a condition, because it is something that happens, so it is an event.
Actions and the Behavior Sentence
An action is what the program does next. Showing a message, locking a row, sending a request and showing an answer are all actions. The sentence "The bench should work well" names no action, because no one could watch the bench do it. The instruction "Show 'Not yet'" does name an action, because a person can see whether it happened.
A behavior sentence has all three parts, in this order: "When [event], if [condition], [action]." The event comes first, because the program responds to something that happens. The condition comes next, because the program checks it at the moment of the event. The action comes last. Engineers at Rolls-Royce developed a method for writing requirements called EARS, first published in 2009, in which the parts of a requirement always appear in the same order. In EARS, a requirement about an event begins with the word "When," just as a behavior sentence does.
One Event, Different Actions
One event can lead to different actions, because the condition decides which action happens. Figure 1 shows this for Bench Basics. The first behavior sentence reads, "When you press Check row, if the row is right, the bench shows 'Right' in green and locks the row." The second reads, "If the row is not right, the bench shows 'Not yet' and counts one misstep." The event is the same press in both sentences, and only the condition is different, so the action is different too.
Code Coach's requirement R5 can also be written as a behavior sentence: "When you press Ask Code Coach, if the box is empty, the bench shows 'Paste or pick a line first.' and sends no request." Its action includes something the bench must not do. A phone gives an everyday case of the same pattern. Apple's support page explains that when a call arrives and an iPhone is in Silent mode, the phone vibrates for the call. The event is the arriving call, the condition is that Silent mode is on, and the action is a vibration instead of a ring.
Many of a program's behavior sentences cover cases that are not the ordinary one. The ordinary case for Check row is a row that is right, but a complete set of rules also says what happens when the row is wrong. EARS has a separate pattern for this purpose, which states how a system responds to situations that are not wanted. The same Apple page adds a case of its own, because calls from favorite contacts still ring in Silent mode. A rule that covers only the ordinary case leaves every other case to whoever writes the code. That person then has to guess, and two people writing the same program can guess in two different ways.
Conditions in Java
In Java, a condition goes in parentheses after the word if, as the small tag under Figure 1 shows. Oracle's Java tutorial explains that the code controlled by an if runs only when the test is true, and the program skips that code when the test is false. The class will read conditions and if statements on Bench Basics from November 30 to December 2, on benches B20 to B22. The true and false from the B07 bench are the same true and false that an if statement checks.
Summary
A program's behavior is written as sentences with an event, a condition and an action, in the order "When [event], if [condition], [action]." An event is something that happens, a condition is a check that is true or false at that moment, and an action is what the program does next. One event can lead to different actions, and a complete set of rules covers the unusual cases as well as the ordinary one.
Sources: Mozilla, Introduction to events (n.d.); Mozilla, XMLHttpRequestEventTarget: load event (n.d.); Oracle, The if-then and if-then-else Statements (n.d.); Mavin, EARS: The Easy Approach to Requirements Syntax (n.d.); Apple, Use the Action button, side button, and other controls on your iPhone (2026); Bench Basics and Code Coach classroom data (2026).
-
notebook cue: event
Name two events that can happen on the Bench Basics page.
Check
Pressing Check row and pressing Next job are two events, and a key press in a table cell, pressing Get credit code now or the page finishing loading also count. Each one is something that happens at one moment that the bench can respond to. See Events and Conditions, paragraph 1.
-
notebook cue: condition
"If the row you filled in is right." Is that an event, a condition or an action, and how can you tell?
Check
It is a condition. It is a check that is either true or false at the moment you press Check row, and nothing happens in it, so it is not an event. See Events and Conditions, paragraph 2, and Figure 1's diamond.
-
notebook cue: action
You press Check row and the row is wrong. What two actions does the bench take?
Check
The bench shows "Not yet" and counts one misstep. Those are the false branch of Figure 1. See One Event, Different Actions, paragraph 1.
-
notebook cue: event
Name two events that can happen on the Bench Basics page.
Check
Pressing Check row and pressing Next job are two events, and a key press in a table cell, pressing Get credit code now or the page finishing loading also count. Each one is something that happens at one moment that the bench can respond to. See Events and Conditions, paragraph 1.
-
notebook cue: condition
"If the row you filled in is right." Is that an event, a condition or an action, and how can you tell?
Check
It is a condition. It is a check that is either true or false at the moment you press Check row, and nothing happens in it, so it is not an event. See Events and Conditions, paragraph 2, and Figure 1's diamond.
-
notebook cue: action
You press Check row and the row is wrong. What two actions does the bench take?
Check
The bench shows "Not yet" and counts one misstep. Those are the false branch of Figure 1. See One Event, Different Actions, paragraph 1.
Events, Conditions and Actions
This section explains how a program's behavior is written as sentences, and the three parts that each of those sentences needs.
Events and Conditions
An event is something that happens that a program can respond to. A click on a button, a key press and a web page finishing loading are all events, according to Mozilla's guide for web developers. A request to a server that finishes with its answer back is also an event, and a page can respond to it. For example, pressing Check row on Bench Basics is an event, because at one moment the button is pressed. The phrase "the box is empty" does not describe an event, because nothing happened, so it describes a condition.
A condition is a check that is either true or false at that moment. The box is empty, the row is right and the input is Java are all conditions. Each one has only two possible answers at a given moment. The phrase "you press Check row" does not describe a condition, because it is something that happens, so it is an event.
Actions and the Behavior Sentence
An action is what the program does next. Showing a message, locking a row, sending a request and showing an answer are all actions. The sentence "The bench should work well" names no action, because no one could watch the bench do it. The instruction "Show 'Not yet'" does name an action, because a person can see whether it happened.
A behavior sentence has all three parts, in this order: "When [event], if [condition], [action]." The event comes first, because the program responds to something that happens. The condition comes next, because the program checks it at the moment of the event. The action comes last. Engineers at Rolls-Royce developed a method for writing requirements called EARS, first published in 2009, in which the parts of a requirement always appear in the same order. In EARS, a requirement about an event begins with the word "When," just as a behavior sentence does.
One Event, Different Actions
One event can lead to different actions, because the condition decides which action happens. Figure 1 shows this for Bench Basics. The first behavior sentence reads, "When you press Check row, if the row is right, the bench shows 'Right' in green and locks the row." The second reads, "If the row is not right, the bench shows 'Not yet' and counts one misstep." The event is the same press in both sentences, and only the condition is different, so the action is different too.
Code Coach's requirement R5 can also be written as a behavior sentence: "When you press Ask Code Coach, if the box is empty, the bench shows 'Paste or pick a line first.' and sends no request." Its action includes something the bench must not do. A phone gives an everyday case of the same pattern. Apple's support page explains that when a call arrives and an iPhone is in Silent mode, the phone vibrates for the call. The event is the arriving call, the condition is that Silent mode is on, and the action is a vibration instead of a ring.
Many of a program's behavior sentences cover cases that are not the ordinary one. The ordinary case for Check row is a row that is right, but a complete set of rules also says what happens when the row is wrong. EARS has a separate pattern for this purpose, which states how a system responds to situations that are not wanted. The same Apple page adds a case of its own, because calls from favorite contacts still ring in Silent mode. A rule that covers only the ordinary case leaves every other case to whoever writes the code. That person then has to guess, and two people writing the same program can guess in two different ways.
Conditions in Java
In Java, a condition goes in parentheses after the word if, as the small tag under Figure 1 shows. Oracle's Java tutorial explains that the code controlled by an if runs only when the test is true, and the program skips that code when the test is false. The class will read conditions and if statements on Bench Basics from November 30 to December 2, on benches B20 to B22. The true and false from the B07 bench are the same true and false that an if statement checks.
Summary
A program's behavior is written as sentences with an event, a condition and an action, in the order "When [event], if [condition], [action]." An event is something that happens, a condition is a check that is true or false at that moment, and an action is what the program does next. One event can lead to different actions, and a complete set of rules covers the unusual cases as well as the ordinary one.
Sources: Mozilla, Introduction to events (n.d.); Mozilla, XMLHttpRequestEventTarget: load event (n.d.); Oracle, The if-then and if-then-else Statements (n.d.); Mavin, EARS: The Easy Approach to Requirements Syntax (n.d.); Apple, Use the Action button, side button, and other controls on your iPhone (2026); Bench Basics and Code Coach classroom data (2026).
Each table writes one sentence for the empty box that says when it happens, in which case, and what the bench does, then checks the sentence against R5.
Chromebooks stay closed while your table talks. Sections 1 and 2 of the discussion form are already done. After you talk, finish Section 3 right here under My View. Submit before the exit ticket.
This form has three sections. Section 1: answer today's Board Question. Section 2: after the reading. Section 3 opens later in class. Today's Board Question: You press Ask in the Code Coach panel without picking a line. What should the bench do, and what should it not do? Write each as one sentence.
CR 1. Board Question: You press Ask in the Code Coach panel without picking a line. What should the bench do, and what should it not do? Write each as one sentence. Give your answer and one reason.
Write your answer in your lab notebook, labeled CR 1.
MC 1. Think about your answer to the board question. You press Ask in the Code Coach panel without picking a line. What should the bench do, and what should it not do? Write each as one sentence. Which position is closest to yours now?
- It should send the empty box to Code Coach and show whatever comes back.
- It should show a short message that says what to do, and send nothing.
- It should do nothing, because the student will notice and paste something.
MC 2. (Reading claim 1) "The student presses Check row" is a condition.
- Agree
- Disagree
MC 3. (Reading claim 2) A condition is a check that is either true or false at that moment.
- Agree
- Disagree
MC 4. (Reading claim 3) If a rule says nothing about a case, the program will do nothing in that case.
- Agree
- Disagree
MC 5. (Reading claim 4) In Figure 1, the true branch and the false branch both start from the same press of Check row.
- Agree
- Disagree
MC 6. (Reading claim 5) When a row is not right, the bench locks the row so that it cannot be changed.
- Agree
- Disagree
MC 7. (Reading claim 6) In Reading 2, System.out.print ends the line after it prints its text.
- Agree
- Disagree
MC 8. (Reading claim 7) In Reading 2, the quotation marks around "Line two" are printed along with the words.
- Agree
- Disagree
MC 9. (Reading claim 8) An iPhone in Silent mode still rings for a call from a favorite contact.
- Agree
- Disagree
CR 2. (A different view) Write the view at your table that was most different from yours. If everyone agreed, write the strongest argument against your table's answer.
Write your answer in your lab notebook, labeled CR 2.
CR 3. Think about the Board Question again: You press Ask in the Code Coach panel without picking a line. What should the bench do, and what should it not do? Write each as one sentence. Do you have the same opinion as when you first answered the board question? If it is the same, what from the reading or table talk reaffirmed your opinion? If it is different, what from the reading or table talk changed your opinion?
Write your answer in your lab notebook, labeled CR 3.