Storing Data in Memory

Every useful program works with data: a player's score, a person's age, a line of text the user typed. Before the program can use any of that data, the data has to be kept somewhere in memory while the program runs. The question this article answers is how a program keeps track of that stored data so that the programmer can work with it comfortably. The answer is the variable, and the central idea is that a variable gives a memory location a name.

As you read, keep one question in mind: when you write a name in your code, what exactly is being looked up? By the end of this article you should be able to trace the path from that name to the data it stands for.

Each part of that definition does real work. Memory location is the physical place where data is stored. Named means that location has been given a label the programmer chooses. Can hold data means the location is where a value lives while the program uses it. Put together, a variable is a labeled spot in memory that holds a value.

Programs need a way to refer to the data they use. A variable provides that way. Because the location has a name, the program can refer to the data through the name rather than needing to know where the location itself is.

A variable involves three things that are easy to blur together: the name you write, the memory location that name is associated with, and the data stored in that location. The source describes the relationship directly: the name identifies the location, while the location holds the data. Follow the chain from left to right in the diagram below.

Read the diagram as a chain. The name score identifies a memory location. That location holds the value 10. The value does not sit in the name, and the name is not the location. The name is the handle the programmer uses to reach the location, and the location is what actually holds the data.

The programmer refers to a variable by its name, not by its memory location. This choice keeps attention on meaningful names such as score rather than on the physical location of the storage. A name like score tells you what the data is for. A location tells you only where it sits, which is a detail that has nothing to do with the problem the program is solving.

Think of the difference between saying 'the value in score' and 'the value in the storage location that was assigned to score.' Both describe the same data, but the first is what a programmer needs to reason about. Naming the data keeps the code readable: when you see score in a program, you know the purpose of the data without decoding where it lives.

If the programmer writes names instead of locations, something has to connect each name to a real memory location. The source assigns that job to the compiler: the compiler is responsible for keeping track of the memory location associated with each name. The programmer does not have to manage that bookkeeping by hand.

This division of labor is the reason names are useful. The programmer writes score and reasons about it as a meaningful quantity. The compiler handles the link from score to the location where the data is kept. The two responsibilities stay separate, and each side can focus on its own job.

Now consider what happens when the data for a name changes. The name stays fixed, and the name still identifies the same memory location. What changes is the data held in that location. The diagram below shows the same name before and after its value is updated.