Research into the use of symbol names, in programming, and how it affects learning

Question

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.

Answer 1

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 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, Buffy in their answer, 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.

Answer 3

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).