Which are common misconceptions about code execution? How to efficiently debug my student?

Question

I may tutor a student who just started learning "school C", by which I mean that strange kind of C seen only on school books (and that in my opinion "cripples the mind", so to say, but I digress). I need to quickly understand her misconceptions, as she is saying that she has many doubts, she says "the char function", "the for function", "no idea what ++ is" and the like.

She looks brilliant nonetheless, besides having great confusion on cs things (and a decreasing engagement of course), therefore I'd prefer a very direct and practical way of getting to her errors, not spending a lot of time repeating concepts that might bore her. I'm quite good at understanding my pupils' mind maps given their answers and fix them but not so good at creating questions/problems that pose the right challenges and let the misconceptions provoke errors in their solutions, mostly because it all seems too simple to me whereas it looks like many students find this topic complex. The only thing that comes to my mind is generating a lot of situations hoping to see her wrong somewhere, clearly not a systematic approach.

Let's say, in our terms, that I don't know well how to identify the corner cases that I ought to be testing and I feel like risking to follow only the happy paths of her thought processes.

For example, I read somewhere that a common misconception is to think that given something like while (relation) { ... } then the student thinks that whenever the relation becomes false something happens (break? I don't know), anywhere in the midst of the block. (I have a compelling feeling of why this specific case might happen).

What are, from your experience (hoping not to make the question too subjective), or from literature, the most common misconceptions and false beliefs that beginning students have? What problems can I give her to extract the most errors?

I think both reading and writing problems, from tracing the execution to fizzbuzz or rainfall style, are there other important exercise types that I shouldn't forget? Anything without code?

Sorry if the question seems boring, I looked for examples a lot, found only a few articles but not really satisfying. Seems that I couldn't find a good catalog of misconceptions and relative inquire methods.

Answer 1

I may add to this as ideas occur to me, but here is a starter version.

You don't state the general academic level of the student, so I'll assume secondary school or beginning university. The student has studied Algebra at least and has some background in math.

The second really big misconception is that a program is just like math. In particular, in C, the misconception that a statement like

x = y + 1;

is an equation to be solved, rather than an operation to be performed. But this is based on the first misconception that a "variable" in algebra is the same sort of thing as a "variable" in programming (in C like languages). In fact, in algebra, a variable doesn't vary, it is a fixed but possibly undetermined value. In C, the value can vary. In algebra, the above represents a relationship. In programming it is an operation. So, first, solve those two possible misconceptions with examples, exercises, and explanations as necessary. Once you do that ++y makes some sense as an operation.

The third big misconception is just that a computer executes an algorithm, which is a sequential execution of defined steps. The program counter, PC, keeps track of the "current state" of the algorithm. In the while loop, the test only gets executed when the PC comes to it in an unrolling of the loop into a sequence of operations.

My personal preference is to teach "variables" as "references to values" not as contents of memory locations. So

x = 5;

means that x refers to 5, not that it is 5. Then you avoid the problem that if the next statement is

x = x + 1;

that the student thinks that five has magically become six. It is just that now x refers to a different value.

---

Caveats.

Note that I'm assuming C-like languages. In lisp-like languages algebra variables and lisp "variables" are actually the same - undetermined/unspecified but immutable values. Also in Fortran IV, you could actually make five magically turn into six. History lesson there, though.

And, of course, modern high performance computers aren't strictly sequential anymore, with speculative execution at branch points.

In fact, with a bit of finesse you can discuss a C program with no reference to any actual machine at all. It defines an algorithm. Full Stop. The finesse part is just about the PC mentioned earlier.