Neither.
At the beginning of the program, set all variables to sane defaults(or accept zero or empty string as a default)
Read the file in, and check for end of file or handle the EOF crash with an ON ERROR. If you hit the end of the file earlier than expected, just silently keep using defaults for the rest of the variables. (If you find that you've hit the end of the file way earlier than expected, like, before any potential new variables that wouldn't be in there yet, you can either continue with defaults as I said, or you can inform the user that their file seems corrupted.)
The next time you save the file, you will save the default values into the file.
To make this easier on yourself in the future, I recommend saving either the version of your program or the version of the save file format as one of the variables in the file. (It can't be one of the first ones now, as that would break backwards compatibility. If you're alright with that, you can make it one of the first ones.)
Any time you make a change to the file format, increment the version.
When your program is reading the file in, you can check the version listed in the file to see what(if any) variables you need to default out.
This method also makes it easier to check if a file is corrupted, if you want to handle that. Check the version of the file, and then see if you can read in all the proper variables for that version. If you can't, the file is corrupt.
For future reference, one of my recommendations for making a file format is to always have the first line/entry in the file be some sort of static string that identifies it as your file type. You can use the name of your program, or an abbreviation, or anything, as long as it's always the same.
This lets you easily check if you're loading the right type of file by just reading the first line in and comparing.
The second line/entry should always be a file format version. That lets you check if you need to update any variables after a program update. If you're careful with it, you could even maintain both backward and forward compatibility in the file, although forward compatibility will generally be more of a hassle, for obvious reasons.
You could still use the version check as a way to tell the user that they're loading a file made with a newer version of your program, and they may lose data if they continue to do so.
Nearly every major file format will do one or both of these things; most of them at least use some form of identifier string(often referred to as a "magic number" or "magic bytes"), and most formats will either have some form of version number, or will actually have different magic bytes depending on the version of the format.
See
en.wikipedia.org/wiki/List_of_file_signatures for a whole bunch of examples. (Quick ones - JPG images always start with "JFIF", BMP images always start with "BM", GIF images always start with "GIF87a" or "GIF89a" depending on the format, Windows executables always start with "MZ", ZIP files always start with "PK", PDF files always start with "%PDF", SQLite databases always start with "SQLite format 3"(indicating both type and version), and PNG images start with a special magic byte sequence that not only includes the letters "PNG", but a whole set of bytes cleverly designed to identify various types of data transmission errors.)
