<p>This may be a result of students not relating their everyday usage of some words to their formal meaning, of course, but the issue really is that you can use teaching strategies to improve that. Some students will fail to "get it" on any given topic no matter what you say, and if you continue to repeat yourself in the same way, especially with the same words and techniques, they will continue to fail to get it. Every student learns differently and most learn differently from the way that you do. </p>

<p>Therefore, you need to approach nearly every topic repeatedly but in a variety of ways. A purely logical approach, for example, reaches only a few students. </p>

<p>Use a variety of things like metaphor and analogy (such as the one you give in the question and examples along with your explanations. Make it visual (not just textual) if you can. Make it active if you can. There are lots of tricks. Use them all. </p>

<p>In the particular example you give, a small improvement might help a few students:</p>

<pre><code>// objectReference might be null
if ( objectReference == null ) {  // object does not exist
    objectType objectReference = new objectType( ... );  // so create it
    ...
}
// objectReference is unchanged here (TY to ctrl-alt-delor)
</code></pre>

<p>However, your use of ellipsis also confuses me. Do you mean to do something only if the reference is originally null or do you mean to put the additional actions outside the closing brace where I put a comment. Also, as ctrl-alt-delor points out in a comment, you have created a new local reference variable within the block, so what occurs after the block is possibly a bit chaotic. It may not be a problem if that is the end of the program, but might be otherwise. </p>

<p>To teach <code>if</code>, you need a lot of examples, not just one. Examples that clearly show the possible execution paths. They need not always be programming examples. Your door example could be couched in programming terms, for example, to connect the analogy to the programming language</p>

<pre><code>if(!doorIsOpen()){
    openDoor();
}
walkThroughDoor();
</code></pre>

<p>Talk about it. Talk about the two original situations with the door. </p>

<p>But more important: don't use just this one example and expect everyone to get it. That is unlikely to happen. Use a different example in which an <code>else</code> is needed. Talk about the difficulty of writing this with condition $doorIsOpen()$ rather than $!doorIsOpen()$. Come at the target (learning) from lots of directions. </p>

<p>A quick, ungraded, pop quiz can also tell you whether they have the concept or whether you need to do more. It can also let you know who you need to work with more intensively. </p>

<p>Be flexible. Surround them with a cloud of understanding. </p>

<hr>

<p>My original answer here, missed the fact that there is a new local variable created in the block. That is part of what confuses me about the example and might be part of what is confusing students if this is a real example, though it may not, in fact, be an actual example presented to students. </p>

CC BY-SA 3.0
2018-03-24T09:30:43.900Z
If you remove the local declaration, then you have a once pattern. A once method only does something the first time it is called. Often used to create an `init` method (for late initialisation), the init method is called at the top of every method. It is responsible for doing it once. I struggle to see a use case for a local shadow variable.
ctrl-alt-delor
CC BY-SA 3.0
2018-03-24T09:39:45.937Z
I think it is really just a case of poor coding. It looks like the poster missed something. It is certainly a poor example for teaching the `if` structure to a novice.
Buffy
CC BY-SA 3.0
2018-03-23T14:13:17.303Z
2018-03-23T16:50:17.590Z
2018-03-23T16:50:17.590Z
Buffy
<p>I find that after teaching for months, some students still get stumped when they try to write code for things like simple two-alternative situations. They have some code for something like:</p>

<pre><code>if ( objectReference == null ) {  // object does not exist
    objectType objectReference = new objectType( ... );  // so create it
    ...
}
</code></pre>

<p>And they can't figure out how to code the case where the object <em>does</em> exist. They say, "How do I test if it IS already there?" And I stand there with a blank look on my face. I am thinking: <em>"Either it's there, or it ain't."</em> Usually, if I stand there looking blank for more than 17 seconds (the time it takes for short-term memories to be stored in long-term memory), they suddenly go, "Uh!" and I laugh nervously and go sit back down.</p>

<p>Then, days or weeks later, it happens again. What better could I do in this situation? How to make the very basics of programming thought <em>stick</em>?</p>

<p>The idea of two-alternative selection seems way more fundamental that just programming. We could not navigate one minute of our lives without already knowing it unconsciously. Come to a door... If not open: open it, else: walk thru. Not so complex. But, making it <em>conscious</em> is a whole other ballgame. People don't really <em>think about</em> what they were doing, and in many cases, this is a good thing. But in programming, we need to know how we are thinking. And think about it. And think about how we think about it. (You get the picture)</p>

CC BY-SA 3.0
2018-03-23T15:15:54.937Z
Note: after the `}`, `objectRefernece` will have the same state as at the start of the code. The new object that you created, is assigned to a local reference. (In most/all C like languages)
ctrl-alt-delor
CC BY-SA 3.0
2018-03-23T15:19:20.850Z
I think your strategy of just waiting for a bit, is a good one (wait time: Wait until you feel that the uncomfortable silence has gone on way to long, then wait a bit longer.)
ctrl-alt-delor
CC BY-SA 3.0
2018-03-23T16:15:45.327Z
Are you saying that students say "uh!" because they've figured it out for themselves, or because you've stared at them for 20 seconds? I've never heard the term "two-alternative selection" before- are you just talking about `else` blocks here?
Kevin Workman
CC BY-SA 3.0
2018-03-23T16:51:36.780Z
TY to @ctrl-alt-delor for pointing out the local variable. I missed it in my original answer, but have corrected it.
Buffy
CC BY-SA 3.0
2018-03-23T17:33:09.530Z
So we have 2 problems: a local variable shadowing another one (got it today in another context with some attributes declarations copied when introducing an abstract parent class), and an apparently "missing else" ?
Michel Billaud
CC BY-SA 3.0
2018-03-24T00:17:50.900Z
"testing if" is not what an if does. It evaluates a condition then if that's true then it executes some code. (An if-else executes a branch per test result.) "Testing if" & "testing whether" *don't even have any clear everyday meanings*. So it is hopeless & ill-considered to refer to them. PS You might find out about the roles of assertions, invariants & contracts in programming.
philipxy
<conceptual-frameworks>
What IF Thinking
# What IF Thinking

(Asked by: username_0 on 2018-03-23)

I find that after teaching for months, some students still get stumped when they try to write code for things like simple two-alternative situations. They have some code for something like:
if ( objectReference == null ) {  // object does not exist
    objectType objectReference = new objectType( ... );  // so create it
    ...
}

And they can't figure out how to code the case where the object does exist. They say, "How do I test if it IS already there?" And I stand there with a blank look on my face. I am thinking: "Either it's there, or it ain't." Usually, if I stand there looking blank for more than 17 seconds (the time it takes for short-term memories to be stored in long-term memory), they suddenly go, "Uh!" and I laugh nervously and go sit back down.
Then, days or weeks later, it happens again. What better could I do in this situation? How to make the very basics of programming thought stick?
The idea of two-alternative selection seems way more fundamental that just programming. We could not navigate one minute of our lives without already knowing it unconsciously. Come to a door... If not open: open it, else: walk thru. Not so complex. But, making it conscious is a whole other ballgame. People don't really think about what they were doing, and in many cases, this is a good thing. But in programming, we need to know how we are thinking. And think about it. And think about how we think about it. (You get the picture)

**Tags:** conceptual-frameworks

> **Comments:**
> **username_1**: Note: after the `}`, `objectRefernece` will have the same state as at the start of the code. The new object that you created, is assigned to a local reference. (In most/all C like languages)  
> **username_1**: I think your strategy of just waiting for a bit, is a good one (wait time: Wait until you feel that the uncomfortable silence has gone on way to long, then wait a bit longer.)  
> **username_2**: Are you saying that students say "uh!" because they've figured it out for themselves, or because you've stared at them for 20 seconds? I've never heard the term "two-alternative selection" before- are you just talking about `else` blocks here?  
> **username_3**: TY to @username_1 for pointing out the local variable. I missed it in my original answer, but have corrected it.  
> **username_4**: So we have 2 problems: a local variable shadowing another one (got it today in another context with some attributes declarations copied when introducing an abstract parent class), and an apparently "missing else" ?  
> **username_5**: "testing if" is not what an if does. It evaluates a condition then if that's true then it executes some code. (An if-else executes a branch per test result.) "Testing if" & "testing whether" *don't even have any clear everyday meanings*. So it is hopeless & ill-considered to refer to them. PS You might find out about the roles of assertions, invariants & contracts in programming.  

---

## 1 answers

### Answer by username_3 on 2018-03-23. Score: 3

This may be a result of students not relating their everyday usage of some words to their formal meaning, of course, but the issue really is that you can use teaching strategies to improve that. Some students will fail to "get it" on any given topic no matter what you say, and if you continue to repeat yourself in the same way, especially with the same words and techniques, they will continue to fail to get it. Every student learns differently and most learn differently from the way that you do. 
Therefore, you need to approach nearly every topic repeatedly but in a variety of ways. A purely logical approach, for example, reaches only a few students. 
Use a variety of things like metaphor and analogy (such as the one you give in the question and examples along with your explanations. Make it visual (not just textual) if you can. Make it active if you can. There are lots of tricks. Use them all. 
In the particular example you give, a small improvement might help a few students:
// objectReference might be null
if ( objectReference == null ) {  // object does not exist
    objectType objectReference = new objectType( ... );  // so create it
    ...
}
// objectReference is unchanged here (TY to username_1)

However, your use of ellipsis also confuses me. Do you mean to do something only if the reference is originally null or do you mean to put the additional actions outside the closing brace where I put a comment. Also, as username_1 points out in a comment, you have created a new local reference variable within the block, so what occurs after the block is possibly a bit chaotic. It may not be a problem if that is the end of the program, but might be otherwise. 
To teach if, you need a lot of examples, not just one. Examples that clearly show the possible execution paths. They need not always be programming examples. Your door example could be couched in programming terms, for example, to connect the analogy to the programming language
if(!doorIsOpen()){
    openDoor();
}
walkThroughDoor();

Talk about it. Talk about the two original situations with the door. 
But more important: don't use just this one example and expect everyone to get it. That is unlikely to happen. Use a different example in which an else is needed. Talk about the difficulty of writing this with condition $doorIsOpen()$ rather than $!doorIsOpen()$. Come at the target (learning) from lots of directions. 
A quick, ungraded, pop quiz can also tell you whether they have the concept or whether you need to do more. It can also let you know who you need to work with more intensively. 
Be flexible. Surround them with a cloud of understanding. 

My original answer here, missed the fact that there is a new local variable created in the block. That is part of what confuses me about the example and might be part of what is confusing students if this is a real example, though it may not, in fact, be an actual example presented to students.

> **Comments:**
> **username_1**: If you remove the local declaration, then you have a once pattern. A once method only does something the first time it is called. Often used to create an `init` method (for late initialisation), the init method is called at the top of every method. It is responsible for doing it once. I struggle to see a use case for a local shadow variable.  
> **username_3**: I think it is really just a case of poor coding. It looks like the poster missed something. It is certainly a poor example for teaching the `if` structure to a novice.  

---

