VariablesHoldExpressions

Incorrect

= stores an expression in a variable

Correct

= evaluates an expression and stores its value in a variable

Correction
Here is what's right.

First, the expression is evaluated. Then the assignment operator (=) stores the resulting value in the variable.

Variables hold values. In Java, an expression is not a value. Thus, variables cannot store expressions. However, an expression can be evaluated, producing a value. That value can then be stored in the variable.

Note that once a value is produced, there is no more connection between that value and the expression that produced it.

Origin
Where could this misconception come from?

This misconception may at least partially be due to students’ familiarity with algebra, where the right hand side of an equation is not evaluated and stored in a variable on the left.

While chances are low, it could be that a student got exposed to “pass-by-name” beforehand.

Symptoms
How do you know your students might have this misconception?

A student holding this misconception may put the expression (not its value) into the box of a memory snapshot diagram. Alternatively, the student may draw an arrow from the box to a heap object holding that expression.

Value
How can you build on this misconception?

This misconception can be very valuable when introducing functional programming, where functions (including anonymous functions, lambdas) are treated as normal values.

If a student (wrongfully) thinks that the following statement stores the unevaluated expression a + 1 in variable inc

inc = a + 1;

…then when introducing lambdas one can explain that the following statement does do that:

inc = a -> a + 1;

Language

Java

Concepts

Expressible In

Related Misconceptions

Other Languages

Literature References

The following papers directly or indirectly provide qualitative or quantitative evidence related to this misconception.

Chiodini et al. 2025

Quantitative systematic research

97 Swiss high school teachers and their students

Python
Artifact

Programming Language Misconceptions studied:
VHE: VariablesHoldExpressions
8 / 97
Teachers hold misconception
58 / 97
Teachers familiar with misconception
Important: 63
Somewhat Important: 14
Not So Important: 10
Not Important: 3
I'm not sure: 7
Importance (reported by teachers)
Frequently: 7
Multiple Times: 24
At Least Once: 17
Never: 42
I don't know: 7
Prevalence in students (reported by teachers)
Bevilacqua et al. 2024

Qualitative and quantitative systematic research

542 hand-drawn expression trees from 12 exams in 6 university courses

Java
Artifact

Diagram mistakes studied:
SubstitutionTakenFromEvaluation: A node is replaced with a subtree containing code that appears inside methods or constructors called by the expression.
62 / 480
Cases
Lu and Krishnamurthi 2024

Quantitative systematic research

Students from 2 universities and other users of online textbook

SMoL
Artifact

Programming Language Behavior Misconceptions studied:
CallByRef: Function calls alias variables
10 %
Learners hold misconception
DefByRef: Variable definitions alias variables
12 %
Learners hold misconception
StructByRef: Data structures might refer to variables by their references
24 %
Learners hold misconception
Lazy: Expressions are only evaluated when their values are needed
57 %
Learners hold misconception
Swidan et al. 2018

Quantitative systematic research

145 participants aged 7-17 with programming experience

Scratch
Artifact

Programming Misconceptions studied:
M15: Primitive assignment stores equations or unresolved expressions
16 / 63
Participants hold misconception
Du Boulay 1986

Argumentation, review of prior work

No explicitly mentioned subjects

Pascal
BASIC

Difficulties studied:
Page66: Variable holds an unevaluated expression

Stay up-to-date

Follow us on  twitter to hear about new misconceptions.