Research into the use of symbol names, in programming, and how it affects learning 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.
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.