<p>You don't have control over the libraries, though you can provide a <em>filter</em> class that, itself, provides better names. Yes, names matter and shouldn't be confusing. </p>

<p>But when <em>you</em> create examples and libraries pay a lot of attention to the names. When you present them to the students and learn that there are confusions, change them. Even better, ask the students to suggest better names. One of the purposes of the Navigator in a Pair Programming scenario is to suggest alternate names to the Driver. </p>

<p>In my somewhat extreme view, every name should be <em>intention revealing</em>. The only exceptions are <em>very</em> common acronyms and abbreviations. But in general, I don't create either acronyms or abbreviations and try to make the names as clear as possible. I fail at this of course, but it is the goal. </p>

<p>However, in the current example, the students should also have a metaphor about the overall structure of the simulated world. Turtles only move in the direction they are facing. They can turn, either <em>left</em> or <em>right</em>. There should also be some per-instruction documentation that makes it clear. If they can learn to think in terms of the metaphor, rather than the detail, they will have an advantage as long as the metaphor itself is sound. </p>

<p>Also, in the current example, I'll note that too many people name things emphasizing short names over self-explanatory names. I sometimes think that they believe that the hard part of programming is the typing. There was a point in time in which program preparation (punch cards) was extremely frustrating but those times are gone. Good IDEs today do typing completion, so names seldom need to be typed in full. But even in the card punch days, <em>real</em> programmers employed data entry clerks who did the card punching from hand written coding sheets. A good clerk could correct quite a few minor errors along the way. </p>

CC BY-SA 4.0
2018-05-14T12:16:17.467Z
2018-05-14T13:06:32.487Z
2018-05-14T13:06:32.487Z
Buffy
<p>The names of symbols in the language, or library, that is being used in the classroom should not have any effect upon student learning.</p>

<hr>

<p>The learning of the students is based more upon the knowledge passed on from the teacher to the students. The language, and its libraries and examples, are mere tools. How they are used, and presented, by the instructor can remove any associated ambiguity that might result from the chosen names if they were encountered "in the wild."</p>

<p>On the other hand, helping the students to handle situations where a symbol's name does not match what they "expect" that it should indicate is a worthwhile goal. There will be many occasions in their future career, if they pursue such, where they will encounter many "names" that don't match what they think they should. The, likely minor, disconnect between expectations and reality of names in languages and libraries should be a good learning tool for when they encounter much larger disconnects in code written by others that they either have to maintain, or interact with in future projects.</p>

<hr>

<p>As mentioned by another user, <a href="https://cseducators.stackexchange.com/users/1293/buffy">Buffy</a> in their <a href="https://cseducators.stackexchange.com/a/4763/104">answer</a>, having a metaphor to deal with the environment of the language, or library, often helps. In widely used languages and libraries the metaphor, if chosen well, will usually be sufficient to make the students comfortable in that environment. With programs found "in the wild" there will often be no useful metaphor available, or likely even possible. Taking advantage of any disconnects that exist in the the language base used in the classroom can help the students learn to adjust to such situations later. It can also be used as an example of why good naming conventions are important.</p>

CC BY-SA 4.0
2018-05-15T07:58:11.990Z
The problem is, when you read `turtle.left(30)`, you have 2 possible understandings : move it 30 units to the left, or change its direction (anti-clockwise).  You have to remember which on is the correct interpretation, which causes an extra cognitive load (we already have to remember the left from the right :-)). So it has a negative impact. Could be avoided with better names.
Michel Billaud
CC BY-SA 4.0
2018-05-15T09:12:59.720Z
@MichelBillaud As I understand it, the turtle cannot *move* left, any more than a car can. That means "left" can only mean "turn" not "move". The *mental model", or metaphor, is incompletely developed if the choice of move or turn arises from the command "left".
Gypsy Spellweaver
CC BY-SA 4.0
2018-05-15T10:45:24.407Z
@GypsySpellweaver the students have no idea that a sprite on the screen can only go forward. What is constrainning it? Yes there is an incomplete metaphor. But we have to start at the beginning. I can see that a way around the problem, is to take them to the playground, and have them pretend to be a turtle. Have some instructions printed, that they can hold. As for words not mattering I have one thing to say to that: Correct horse battery staple.
ctrl-alt-delor
CC BY-SA 4.0
2018-05-15T13:21:11.457Z
@GyspySpellweaver moving to the *left of the screen*, if you are not lucky enough to have a real robotic turtle on the floor. It is a *simulation* only.
Michel Billaud
CC BY-SA 4.0
2018-06-25T17:13:01.657Z
@GypsySpellweaver should we likewise, in literacy class, give examples of poor punctuation, spelling and grammar, because they will see it in the real world.
ctrl-alt-delor
CC BY-SA 4.0
2018-06-25T17:54:29.623Z
@ctrl-alt-delor If you were teaching those who would become copy editors, or that would have to deal professionally with updating/changing the work of others in that field, then __yes__ you should. The experience and exposure will help them.
Gypsy Spellweaver
CC BY-SA 4.0
2018-06-25T18:04:14.967Z
@GypsySpellweaver So should we give them this bad copy every lesson, and tell them that this is best practice? Or some lessons, where we ask them to correct it?
ctrl-alt-delor
CC BY-SA 4.0
2018-06-25T19:43:57.707Z
@ctrl-alt-delor Once the course (back to CS) has covered "best practice" for naming, and a library is used that does cause student confusion for lack of same, then it becomes a _teaching moment_ to emphasise the "why" for using naming conventions as well as practice for sussing out what it's supposed to do despite the confusing name. Changing the past (rewriting a common library) is difficult to do. Teaching from past mistakes to create a better future is likely to be a more fruitful, and efficient, use of instructor energies.
Gypsy Spellweaver
CC BY-SA 4.0
2018-06-26T07:44:15.087Z
@GypsySpellweaver I think we are in agreement. However I am not asking if I should re-write the libraries. I am asking if there is research on the effect (of using bad names, in a beginner class: first lesson of programming). This will tell us what to do: What libraries to choose, should we write a language/library for training/education. But I am not asking these questions here now.
ctrl-alt-delor
CC BY-SA 4.0
2018-05-15T00:08:49.183Z
2018-05-15T00:08:49.183Z
Gypsy Spellweaver
<p><strong>Separate the actual solution, from the code</strong></p>

<hr>

<p>As you've probably identified, the underlying issue is not that the names are incomprehensible or that the students lack memory in remembering what 4 simple commands do.</p>

<p>Instead, it's that trying to remember your step-by-step solution; <strong>and</strong> translate it into those 4 commands - becomes too much to handle all at once.</p>

<p>Importantly, by trying to do it all at once, the students give themselves the opportunity to get confused between what actions they can do (turn left, move forward) and the names of the variables (does "left" actually mean we can move left?).</p>

<hr>

<p>As with any programming task - I'd suggest breaking it back into the two separate phases:</p>

<ul>
<li>Creating a language agnostic solution</li>
<li>Translating the solution into code</li>
</ul>

<hr>

<p>Firstly, make the problem clear - in non-python terms. You have a turtle that can move forwards, turn-clockwise or anti-clockwise; and you need give it a set of instructions to get to a destination.</p>

<p>This is agnostic of the library used to implement it, or even the fact they will be programming the turtle. As you suggested in the comments - you can have them solve this in person, in the playground, if it's helpful; as it is entirely decoupled from the act of typing code.</p>

<p>This solution should be written, using any natural language they prefer (including diagrams where they feel it's useful). Importantly, it should be complete enough they could pass it to another student - and have them verify it's correct - without ever typing a line of python code.</p>

<p><em>The benefit of having it written down, is you reduce the amount of things they need to remember at any one stage. As they become more experienced, they will naturally find their need to do this drops - but early on, it is a very good habit to develop.</em></p>

<hr>

<p>Once the students have a written solution, in their own choice of natural language (but importantly, written, and not just sitting in thier heads). You can move onto translating their solution into python.</p>

<p>Note that in the translation stage, they should feel that the problem is already solved. This stage should be made clear, that it is a mechanical translation from one language (theirs) to another (python).</p>

<p>Here, although the names may be slightly confusing - it now shouldn't matter. By having them translate their written solution - they are simply looking for the python commands which represent their chosen action. It doesn't matter that "left" sounds like "move left"; as their solution will not contain any references to strafing left (based on the original plain-english problem statement).</p>

<p>Once they have translated their solution, and tested it. It's important again, to emphasise <strong>not fixing the bugs directly</strong>. At all stages, their written solution should be corrected first, and the actual coding should never be more than translating written language into python code.</p>

<hr>

<p>With this, hopefully it's clear how the students will develop two separate mental models. One for how to solve problems - given a limited set of instructions - and one for the actual code that represents their solution (which may or may not have intuitive names).</p>

CC BY-SA 4.0
2018-06-25T17:08:01.933Z
While not directly answering the question, this answer does have a log of value. I suspect that the gap that it discusses, is widened by the use of poor names. The more unlike their native language, the wider the gap will be. Well written python, with good name, can look like english (may be any other language), but with strange punctuation.
ctrl-alt-delor
CC BY-SA 4.0
2018-06-25T14:38:16.823Z
2018-06-25T14:38:16.823Z
Bilkokuya
<p>When programming we need to name things. I have been using turtle graphics in python, and was wondering if the names, chosen, for the commands, were making it more difficult for my pupils.</p>

<p>Some of the turtle commands are:</p>

<pre><code>turtle.left
turtle.right
turtle.forward
turtle.backward
</code></pre>

<p>Pupils often get confused, because they think that <code>turtle.left</code> will make the turtle move to the left. Would learning be improved, if the language/libraries chose better names? e.g.</p>

<pre><code>turtle.turn_left
turtle.turn_right
turtle.move_forward
turtle.move_backward
</code></pre>

<hr>

<p>This is not about students choosing good name, but about names used by the  libraries, and examples.</p>

CC BY-SA 4.0
2018-05-14T12:06:04.097Z
Possible duplicate of [How can we teach good naming practice for students learning Java?](https://cseducators.stackexchange.com/questions/4594/how-can-we-teach-good-naming-practice-for-students-learning-java)
Buffy
CC BY-SA 4.0
2018-05-14T12:06:07.637Z
@Buffy your question seems to be about teaching students to use good names. My question is about teachers using good names (choosing languages, and libraries etc.).
ctrl-alt-delor
CC BY-SA 4.0
2018-05-14T13:14:12.680Z
I note that this isn't a research question. In fact it would likely be considered unethical to do the experiment as you would be subjecting some students to practices that you already think might be worse than others. This sort of thing makes ed research very tricky. You aren't allowed to disadvantage someone just to learn something.
Buffy
CC BY-SA 4.0
2018-05-14T17:49:19.420Z
@Buffy so instead we continue to subject all pupils to a practice that we think may be worse. That is logic (should the members of the ethics board do a CS course?).
ctrl-alt-delor
CC BY-SA 4.0
2018-05-14T18:29:45.733Z
You are misconstruing my words. Please stop. If you think something is an improvement, use it. If you later get evidence otherwise, stop it.
Buffy
CC BY-SA 4.0
2018-05-14T23:15:09.503Z
I do not see this as a duplicate of the question about teaching naming practices. As the OP has stated this is about the names already assigned in existing libraries, and language bases, and how those names affect the students' learning.
Gypsy Spellweaver
CC BY-SA 4.0
2018-06-21T21:20:58.297Z
You need to teach them that names mean nothing. That includes disabusing them of the notion that names mean something. Names label things.
philipxy
CC BY-SA 4.0
2018-06-22T11:06:54.727Z
@philipxy can you elaborate? Are you saying that because the compile just sees the names as labels then so should we? This is a valid point of view, but if we see it that way then we should act on our belief and use truly abstract sequential names, and not think about them. `aaaaaaaa`, `aaaaaaab`, `aaaaaaac`, etc.
ctrl-alt-delor
CC BY-SA 4.0
2018-06-22T19:13:11.333Z
Names are labels. In general we can infer nothing from the names of things. (This has nothing to do with implementation, which has nothing to do with the meanings of programs.) In everyday life we are used to names frequently also being descriptive of their referents. But this cannot be relied on. Nor can it be in a technical context. All we can rely on is definitions, axioms, theorems & sound reasoning. Understanding this is fundamental to competent technical work. People must be actively disabused of their naive expectations. French toast is not toast. `=` is not equality if `not (NaN=NaN)`.
philipxy
CC BY-SA 4.0
2018-06-22T19:13:18.063Z
... Nevertheless mnemonic names are helpful. And memorability is with respect to the structure/organization of the system/metaphor they apply to. So poorly chosen collections of names are hard to remember. But this applies to all use, not just learning.
philipxy
CC BY-SA 4.0
2018-06-22T20:12:45.010Z
I can not make any sense from philipxy's comments, but if anyone else can. Then please help by leaving a comment, with explanation/translation.
ctrl-alt-delor
CC BY-SA 4.0
2018-06-22T20:13:51.480Z
What is the first thing you don't understand?
philipxy
CC BY-SA 4.0
2018-06-22T20:25:46.760Z
It is not clear what you want to ask. Ok, "Would [beginner?] learning be improved, if the language/libraries chose better names?" isn't a case of "how do we teach good naming". But it is true by definition of "better" & is a case of "would use [by everyone] be improved if people chose better names?"--also vacuous, begging "what is good naming?" 4 (!) other phrases (title, "wondering if", "this is about" & a comment) don't clarify how this is not vacuous or just a special case or how it is not actually what you mean to ask. Please replace the 5 by 1 clear question. And of what use is an answer?
philipxy
<best-practice><introductory-lesson>
Research into the use of symbol names, in programming, and how it affects learning
# Research into the use of symbol names, in programming, and how it affects learning

(Asked by: username_0 on 2018-05-14)

When programming we need to name things. I have been using turtle graphics in python, and was wondering if the names, chosen, for the commands, were making it more difficult for my pupils.
Some of the turtle commands are:
turtle.left
turtle.right
turtle.forward
turtle.backward

Pupils often get confused, because they think that turtle.left will make the turtle move to the left. Would learning be improved, if the language/libraries chose better names? e.g.
turtle.turn_left
turtle.turn_right
turtle.move_forward
turtle.move_backward


This is not about students choosing good name, but about names used by the  libraries, and examples.

**Tags:** best-practice, introductory-lesson

> **Comments:**
> **username_1**: Possible duplicate of [How can we teach good naming practice for students learning Java?](https://cseducators.stackexchange.com/questions/4594/how-can-we-teach-good-naming-practice-for-students-learning-java)  
> **username_0**: @username_1 your question seems to be about teaching students to use good names. My question is about teachers using good names (choosing languages, and libraries etc.).  
> **username_1**: I note that this isn't a research question. In fact it would likely be considered unethical to do the experiment as you would be subjecting some students to practices that you already think might be worse than others. This sort of thing makes ed research very tricky. You aren't allowed to disadvantage someone just to learn something.  
> **username_0**: @username_1 so instead we continue to subject all pupils to a practice that we think may be worse. That is logic (should the members of the ethics board do a CS course?).  
> **username_1**: You are misconstruing my words. Please stop. If you think something is an improvement, use it. If you later get evidence otherwise, stop it.  
> **username_2**: I do not see this as a duplicate of the question about teaching naming practices. As the OP has stated this is about the names already assigned in existing libraries, and language bases, and how those names affect the students' learning.  
> **username_3**: You need to teach them that names mean nothing. That includes disabusing them of the notion that names mean something. Names label things.  
> **username_0**: @username_3 can you elaborate? Are you saying that because the compile just sees the names as labels then so should we? This is a valid point of view, but if we see it that way then we should act on our belief and use truly abstract sequential names, and not think about them. `aaaaaaaa`, `aaaaaaab`, `aaaaaaac`, etc.  
> **username_3**: Names are labels. In general we can infer nothing from the names of things. (This has nothing to do with implementation, which has nothing to do with the meanings of programs.) In everyday life we are used to names frequently also being descriptive of their referents. But this cannot be relied on. Nor can it be in a technical context. All we can rely on is definitions, axioms, theorems & sound reasoning. Understanding this is fundamental to competent technical work. People must be actively disabused of their naive expectations. French toast is not toast. `=` is not equality if `not (NaN=NaN)`.  
> **username_3**: ... Nevertheless mnemonic names are helpful. And memorability is with respect to the structure/organization of the system/metaphor they apply to. So poorly chosen collections of names are hard to remember. But this applies to all use, not just learning.  
> **username_0**: I can not make any sense from username_3's comments, but if anyone else can. Then please help by leaving a comment, with explanation/translation.  
> **username_3**: What is the first thing you don't understand?  
> **username_3**: It is not clear what you want to ask. Ok, "Would [beginner?] learning be improved, if the language/libraries chose better names?" isn't a case of "how do we teach good naming". But it is true by definition of "better" & is a case of "would use [by everyone] be improved if people chose better names?"--also vacuous, begging "what is good naming?" 4 (!) other phrases (title, "wondering if", "this is about" & a comment) don't clarify how this is not vacuous or just a special case or how it is not actually what you mean to ask. Please replace the 5 by 1 clear question. And of what use is an answer?  

---

## 3 answers

### Answer by username_1 on 2018-05-14. Score: 7

You don't have control over the libraries, though you can provide a *filter* class that, itself, provides better names. Yes, names matter and shouldn't be confusing.

But when *you* create examples and libraries pay a lot of attention to the names. When you present them to the students and learn that there are confusions, change them. Even better, ask the students to suggest better names. One of the purposes of the Navigator in a Pair Programming scenario is to suggest alternate names to the Driver.

In my somewhat extreme view, every name should be *intention revealing*. The only exceptions are *very* common acronyms and abbreviations. But in general, I don't create either acronyms or abbreviations and try to make the names as clear as possible. I fail at this of course, but it is the goal.

However, in the current example, the students should also have a metaphor about the overall structure of the simulated world. Turtles only move in the direction they are facing. They can turn, either *left* or *right*. There should also be some per-instruction documentation that makes it clear. If they can learn to think in terms of the metaphor, rather than the detail, they will have an advantage as long as the metaphor itself is sound.

Also, in the current example, I'll note that too many people name things emphasizing short names over self-explanatory names. I sometimes think that they believe that the hard part of programming is the typing. There was a point in time in which program preparation (punch cards) was extremely frustrating but those times are gone. Good IDEs today do typing completion, so names seldom need to be typed in full. But even in the card punch days, *real* programmers employed data entry clerks who did the card punching from hand written coding sheets. A good clerk could correct quite a few minor errors along the way.


---

### Answer by username_2 on 2018-05-15. Score: 2

The names of symbols in the language, or library, that is being used in the classroom should not have any effect upon student learning.

---

The learning of the students is based more upon the knowledge passed on from the teacher to the students. The language, and its libraries and examples, are mere tools. How they are used, and presented, by the instructor can remove any associated ambiguity that might result from the chosen names if they were encountered "in the wild."

On the other hand, helping the students to handle situations where a symbol's name does not match what they "expect" that it should indicate is a worthwhile goal. There will be many occasions in their future career, if they pursue such, where they will encounter many "names" that don't match what they think they should. The, likely minor, disconnect between expectations and reality of names in languages and libraries should be a good learning tool for when they encounter much larger disconnects in code written by others that they either have to maintain, or interact with in future projects.

---

As mentioned by another user, [username_1](https://cseducators.stackexchange.com/users/1293/buffy) in their [answer](https://cseducators.stackexchange.com/a/4763/104), having a metaphor to deal with the environment of the language, or library, often helps. In widely used languages and libraries the metaphor, if chosen well, will usually be sufficient to make the students comfortable in that environment. With programs found "in the wild" there will often be no useful metaphor available, or likely even possible. Taking advantage of any disconnects that exist in the the language base used in the classroom can help the students learn to adjust to such situations later. It can also be used as an example of why good naming conventions are important.

> **Comments:**
> **username_4**: The problem is, when you read `turtle.left(30)`, you have 2 possible understandings : move it 30 units to the left, or change its direction (anti-clockwise).  You have to remember which on is the correct interpretation, which causes an extra cognitive load (we already have to remember the left from the right :-)). So it has a negative impact. Could be avoided with better names.  
> **username_2**: @MichelBillaud As I understand it, the turtle cannot *move* left, any more than a car can. That means "left" can only mean "turn" not "move". The *mental model", or metaphor, is incompletely developed if the choice of move or turn arises from the command "left".  
> **username_0**: @GypsySpellweaver the students have no idea that a sprite on the screen can only go forward. What is constrainning it? Yes there is an incomplete metaphor. But we have to start at the beginning. I can see that a way around the problem, is to take them to the playground, and have them pretend to be a turtle. Have some instructions printed, that they can hold. As for words not mattering I have one thing to say to that: Correct horse battery staple.  
> **username_4**: @GyspySpellweaver moving to the *left of the screen*, if you are not lucky enough to have a real robotic turtle on the floor. It is a *simulation* only.  
> **username_0**: @GypsySpellweaver should we likewise, in literacy class, give examples of poor punctuation, spelling and grammar, because they will see it in the real world.  
> **username_2**: @username_0 If you were teaching those who would become copy editors, or that would have to deal professionally with updating/changing the work of others in that field, then __yes__ you should. The experience and exposure will help them.  
> **username_0**: @GypsySpellweaver So should we give them this bad copy every lesson, and tell them that this is best practice? Or some lessons, where we ask them to correct it?  
> **username_2**: @username_0 Once the course (back to CS) has covered "best practice" for naming, and a library is used that does cause student confusion for lack of same, then it becomes a _teaching moment_ to emphasise the "why" for using naming conventions as well as practice for sussing out what it's supposed to do despite the confusing name. Changing the past (rewriting a common library) is difficult to do. Teaching from past mistakes to create a better future is likely to be a more fruitful, and efficient, use of instructor energies.  
> **username_0**: @GypsySpellweaver I think we are in agreement. However I am not asking if I should re-write the libraries. I am asking if there is research on the effect (of using bad names, in a beginner class: first lesson of programming). This will tell us what to do: What libraries to choose, should we write a language/library for training/education. But I am not asking these questions here now.  

---

### Answer by username_5 on 2018-06-25. Score: 2

**Separate the actual solution, from the code**

---

As you've probably identified, the underlying issue is not that the names are incomprehensible or that the students lack memory in remembering what 4 simple commands do.

Instead, it's that trying to remember your step-by-step solution; **and** translate it into those 4 commands - becomes too much to handle all at once.

Importantly, by trying to do it all at once, the students give themselves the opportunity to get confused between what actions they can do (turn left, move forward) and the names of the variables (does "left" actually mean we can move left?).

---

As with any programming task - I'd suggest breaking it back into the two separate phases:

* Creating a language agnostic solution
* Translating the solution into code

---

Firstly, make the problem clear - in non-python terms. You have a turtle that can move forwards, turn-clockwise or anti-clockwise; and you need give it a set of instructions to get to a destination.

This is agnostic of the library used to implement it, or even the fact they will be programming the turtle. As you suggested in the comments - you can have them solve this in person, in the playground, if it's helpful; as it is entirely decoupled from the act of typing code.

This solution should be written, using any natural language they prefer (including diagrams where they feel it's useful). Importantly, it should be complete enough they could pass it to another student - and have them verify it's correct - without ever typing a line of python code.

*The benefit of having it written down, is you reduce the amount of things they need to remember at any one stage. As they become more experienced, they will naturally find their need to do this drops - but early on, it is a very good habit to develop.*

---

Once the students have a written solution, in their own choice of natural language (but importantly, written, and not just sitting in thier heads). You can move onto translating their solution into python.

Note that in the translation stage, they should feel that the problem is already solved. This stage should be made clear, that it is a mechanical translation from one language (theirs) to another (python).

Here, although the names may be slightly confusing - it now shouldn't matter. By having them translate their written solution - they are simply looking for the python commands which represent their chosen action. It doesn't matter that "left" sounds like "move left"; as their solution will not contain any references to strafing left (based on the original plain-english problem statement).

Once they have translated their solution, and tested it. It's important again, to emphasise **not fixing the bugs directly**. At all stages, their written solution should be corrected first, and the actual coding should never be more than translating written language into python code.

---

With this, hopefully it's clear how the students will develop two separate mental models. One for how to solve problems - given a limited set of instructions - and one for the actual code that represents their solution (which may or may not have intuitive names).

> **Comments:**
> **username_0**: While not directly answering the question, this answer does have a log of value. I suspect that the gap that it discusses, is widened by the use of poor names. The more unlike their native language, the wider the gap will be. Well written python, with good name, can look like english (may be any other language), but with strange punctuation.  

---

