File I/O code needs to be refactored as it is a mess about vampire HOT 5 OPEN

@richard-evans what do you think of using a pre-existent format such as yaml, json or INI files.

from vampire.

The format of the input files is fine as far as I am concerned (they are meant to be read and written by humans), but the processing code for them is unwieldy (3500+ lines of code in a single file). Eventually these will probably be refactored into an i/o module incorporating some new features such as a command line manual.

from vampire.

Separating the input into a separated module would make it a little bit more manageable for sure, specially you break it down to smaller files. In order to get it better, maybe we can make an approach with an Option class, so that all options get parsed automatically, a register for all the options, so there should be just one file listing all of them, and maybe a command pattern, through which the side effects of options and flags can be specified using simple functions.

from vampire.

An option class is an interesting idea. I had a look at this but everything gets a little crazy with templates and I kind of got stuck with the complexity of the solution (elegant for the coder but horrendous for the designer!). At the moment I have stuck with the current code design but with new options moved to an interface file in each submodule of vampire, which keeps things tidier for now. However, I would really like to include a command line help and also have a searchable list of options, which would require some central options class-type solution. Maybe the best way is to have distributed command registration but central parsing. Some more thought is required here I think...

from vampire.

Learning from somewhere else might help as well, I think this problem is common to several packages out there, maybe we should look for some on github see what they do.

from vampire.