Learn
8.3.1 | WHY PROGRAMS STORE DATA IN FILES
01 | THE GAME FORGETS YOUR BEST SCORE
You finish a game with a personal best of twelve points. The score appears on screen, but after closing and reopening the game it starts at zero. Why did displaying twelve not make the game remember it?
While a program runs, variables hold its working data. Those ordinary working values are not automatically saved for a future run. When the process ends, its in-memory state is no longer available to the next process as the same variables.
To remember the personal best, the program needs to store the data somewhere persistent and retrieve it later. A file is one way to do that. Showing a result, holding it in a variable and saving it are different actions.
02 | WHAT IS A DATA FILE?
A file is a named collection of data kept on a storage system. It might contain a high score, a list of students, saved settings or measurements from an experiment.
Persistent data remains available beyond the run that created it. A saved file on non-volatile storage can remain after the program closes and after the device is switched off.
Persistence does not mean indestructibility. A file can still be deleted, overwritten, corrupted or lost with a failed storage device. The point is that it does not depend on the original program continuing to run.
03 | WORKING MEMORY AND SAVED STORAGE
RAM is volatile working memory: its contents are lost without power. Programs normally use it to hold current working information. Non-volatile storage, such as an SSD, keeps stored data without continuous power.
A program reads saved data into its working variables, processes it and may write updated data back. The file and the variable are separate representations, not one automatically synchronised value.
Closing a program releases its ordinary process state even if the computer remains powered. Turning off the device also removes volatile RAM contents. A successfully saved file is intended to remain in storage.
| Working data in a variable | Saved data in a file |
|---|---|
| Used during the current execution | Available to later executions if retained and accessible |
| Changes when instructions assign to it | Changes when file-writing operations save data |
| Ordinary process state ends with the program | Does not require the original process to keep running |
| Not automatically a backup | Still needs protection from deletion or loss |
04 | FOLLOW THE SAVE-AND-LOAD CYCLE
Saving writes data from the running program into a file. Loading reads data from a file so the program can use it.
For a high score, load the saved best when the game starts, compare it with the new score, and save an updated best when required. A later run loads that saved result.
START A RUN
Read the saved best score from the file.
USE WORKING DATA
Compare and update the current variable.
SAVE
Write the required value back to storage.
A LATER RUN
Read the retained file into new working variables.
This is a logical sequence, not a claim that every game saves at the same moment. Saving may happen on a button press, after a completed action or through autosave.
05 | A CHANGED VARIABLE DOES NOT CHANGE THE FILE
Suppose best-score.txt contains eight. Loading creates a working BestScore value of eight. A new result changes that variable to twelve.
Until the program successfully writes twelve to the file, the saved value remains eight. Closing before saving means a later run can load only the old saved eight.
Conversely, OUTPUT BestScore displays twelve but does not itself write to best-score.txt. The user seeing the value on screen is not evidence that a save has completed.
| Stage | Working BestScore | Saved file value |
|---|---|---|
| Before load | Not yet assigned | 8 |
| After load | 8 | 8 |
| After a new personal best | 12 | 8 |
| After successful save | 12 | 12 |
| After close | Current run has ended | 12 |
| Next run loads | 12 | 12 |
06 | TRY SAVING, CLOSING AND REOPENING
The illustration starts with a simulated saved best of eight. Set a new working score, then choose whether to save before closing. Reopen to see which saved value is loaded.
This is a simulation of the distinction between working and saved values. It does not create a file on your device. Its state lasts while this webpage is open; reset returns both values to eight.
07 | WHY KEEP DATA BETWEEN RUNS?
Progress: a revision app can restore completed topics rather than making a student start again.
Settings: a program can reuse a chosen theme or accessibility setting without asking on every launch.
Records: a school tool can retain attendance or experiment results for later analysis.
Reusable input: a question bank stored as data can be loaded repeatedly rather than typed again for every session.
Each example has a clear reason to retain information. Temporary calculation steps do not necessarily need saving: store what a later task actually requires.
08 | DATA IS DIFFERENT FROM THE PROGRAM CODE
The program contains instructions. A data file contains information those instructions use. A quiz’s questions and answers can be data; the rules for displaying them and checking an answer are code.
Keeping data in a separate file can allow a question list to be updated without rewriting the program’s logic, provided the new data follows the expected format.
Saving a source-code file preserves the instructions you wrote. It does not automatically save the live values of variables from the last execution. Those values need an appropriate data-saving operation.
09 | TEXT FILES ARE A USEFUL STARTING POINT
A text file stores data represented as text characters. For introductory file handling, a simple file might contain one score per line or one student name per line.
A saved score can appear as the characters “12”. When the program needs to calculate with that data, it must interpret it as the required numeric type rather than assume all text is already a valid number.
Not every file is plain text. Images, audio and many application documents use other formats. This lesson focuses on why data is stored; the next lessons teach Cambridge’s text-file operations.
10 | AGREE ON THE FORMAT
A file format describes how the saved data is organised and interpreted. A program that expects one INTEGER score per line should not receive unexplained headings or mixed values in that same position.
Saving and loading must follow the same arrangement. If the program writes a name followed by a score, its reading logic needs to know that order.
A readable text file is still not self-validating. Missing lines, invalid numbers or unexpected content need suitable handling. A meaningful filename helps users and developers identify its purpose but does not guarantee its contents.
11 | ARRAYS AND FILES HAVE DIFFERENT JOBS
An array groups related values for the running program to access by index. A file keeps data on storage. A program can read file data into an array, process its elements and write selected results back.
Declaring Scores : ARRAY[1:5] OF INTEGER does not make a persistent file. Likewise, saving five scores does not automatically recreate a correctly initialised array in the next run; the program must load and assign them.
The structures work together: arrays support current processing, while files support retention and later retrieval.
12 | PLAN WHAT HAPPENS ON FIRST RUN
A program’s first run may have no existing data file. A high-score system could use a default best of zero and create the saved data when appropriate.
A missing file is different from a file containing zero. It is also different from a file containing invalid text. The program needs to distinguish those situations rather than assume every read succeeds.
Other failures can include an inaccessible location, insufficient permission, no free space or a damaged file. A save should be reported as successful only when it has actually completed.
13 | SAVING IS NOT THE SAME AS BACKING UP
A saved file may be the only current copy. If it is accidentally overwritten or the storage device fails, persistence alone will not recover the earlier data.
A backup is an additional recoverable copy kept to protect against loss. For important records, appropriate backups and access controls matter alongside correct save-and-load behaviour.
A local file, a cloud file and a database are different storage arrangements, but all can support persistent data. Choosing a file does not automatically make data encrypted, private or backed up.
14 | EXPLAIN THE NEED IN A SCENARIO
For a game: “The best score is stored in a file so it can be loaded in a later session, therefore the player’s previous achievement is retained after the program closes.”
For an experiment: “Readings are saved so the results can be analysed later without repeating the measurements or re-entering the data.”
A strong answer names the data, states the retention requirement and connects storage to its later use. “Files are useful” is too vague. “Files never lose data” is inaccurate.
15 | KEEP THE THREE ACTIONS DISTINCT
Assigning changes working values. Outputting communicates information. Saving writes data into persistent storage. Loading retrieves retained data for a new run.
Files let programs retain progress, settings and records beyond the original execution. They also introduce responsibilities: use a consistent format, handle missing or invalid data and do not claim a failed save succeeded.
The next lesson introduces opening, reading and closing a text file. You will see the explicit instructions that carry out the loading step described here.