The project being described here sounds very similar to my Arena program for OSR-style classic D&D that I've maintained for about ten years now. Reflecting back on that, here's a few organizational tips I might share.
Anything in those kinds of game systems that gets presented in a table format or stat block is a sign of characteristics that are well-defined, vary often but in minimal ways, and are ripe for storage in a database format. For example in my case: the class levels, monsters, treasure types, saving throws, XP awards, and lots of similar stuff.
Things in the game system that are functional and presented as a paragraph block of text are less susceptible to this kind of abstraction. Usually any new kind of feature like this requires some custom code to implement. For example in my case, the monster database includes keywords for various abilities, but each of those needed custom implementation code, and the code structure is a slightly unwieldy giant switch block (in this file).
Similarly, a later addition was an implementation of many of the wizard attack spells in the original game -- stat-block things like level, range, and duration were obvious abstractions (here), but each spell needs custom code to simulate the text effect, and they way they get linked and used by each wizard character is a bit convoluted (here).
As you go forward, be sensitive to moments where you find yourself making minor changes to code and re-compiling over and over again as you iterate on certain experiments. (E.g.: If I want detailed printouts of two specific monsters in a fight, and I keep fiddling with two constants to identify which ones to focus on.) Or, if you start maintaining big initialization lists, and frequently modifying or extending them -- that's something that in the game would be presented as a table, and should be extracted to a data file.
Once you have a file-reading format and facility in your code, and you make a single object/database type that can read the stats from a file like that, you'll find that it's exceedingly easy to copy and modify that kind of code for new tables. Hopefully you get in the habit that when you see or think of a new table, the easiest thing to do will be to just instinctively implement that as a separate data file.
Briefly, among the many benefits are: (1) you can quickly modify data en masse without the delay of opening, editing, compiling code, (2) you can use spreadsheet tools to immediately view, sort, organize, highlight, compute stats on your data, (3) non-coders can view and tweak the data as desired, (4) the data can be exported, reported, and integrity-checked by other external tools, (5) the data can be easily moved and used in a completely different program (e.g., the monster database was re-used in my wilderness encounter simulator).
