Say you have some kind of read-only object data that you need to use in your application. You'll never need to write to or update this data at runtime. But you'll need to read from it a lot.
Do you store it in a .csv file or similar and load it into objects/structs at startup, or do you just hardcode it using enums with corresponding 'getter' functions?
For context, I always seem to think the enum option is a good idea, but I can never quite justify using it.
@VD15 depends on backwards compat concerns, but out of context the hardcoded enum is a better idea, it's effectively the same thing as any other default value that will never be changed outside a new version of the software. There's people that keep all default values and other constants in config files despite not supporting changing them but imo it's a pointless overkill with only downsides.
@VD15 config is something you'd possibly like to configure within a single version, extending it to mean all defaults is misguided imo. That approach has one upside I failed to mention though, sometimes it turns out you'd actually want to configure something that was supposed to be set in stone, in which case config files allow you to do that. If you're making a game with a bunch of items like lelu guessed, having them in a bunch of files you load at startup makes modding in new items or modifying existing ones much easier.
@Amikke That’s an interesting way of thinking about it. I’m always told that config variables & such should be put into separate files but unless it’s something user-facing or sensitive, I rarely see the point