Discussion: General Code Structure

[billdenney]

Prior to starting coding, I'd like to ensure that we're on the same page about how the code will work. My thoughts are as follows, but please don't take this as a well-thought-out, set-in-stone idea. In my mind, it's brainstorming.

• There will be one controller function whose sole job will be to run all of the different potential tests and cleaners.
  • It would be called as something like mrg_data_cleaner(data, model, ..., additional_tests=list()) where each of these is passed to all cleaners and tests.
  • data may not be missing, and it must be data.frame-like (coding should be geared toward tibbles, and we may want to just coerce to a tibble so that output is always structured identically.
  • model may be missing, but that would prevent some tests (such as checking for NA values in model parameters).
  • ... will not be required, and reasonable default arguments will be used for all cleaners.
  • additional_tests would be a list of functions that the user could add which would be specific to their use cases (following the same interface as below).
  • The default test list would be all exported functions whose names start with mrg_data_check_ in the mrgsolve.data namespace.
• Each individual cleaner would be named in a structured way like mrg_data_check_<description>(data, model, specific_argument, ...)
  • The specific_argument names should generally be unique, but in some cases they may be shared (e.g. a flag to actually modify the data rather than report on potential issues).
  • The check functions would return the data, possibly modified.
• Likely shared arguments across many (and maybe all) functions could be:
  • action=c("warn", "clean") where both are allowed. "warn" would give a warning for data issues, "clean" would fix the issue.
  • stop_on_error=TRUE, indicates if issues that would prevent accurate use of the data that cannot be cleaned automatically. FALSE would indicate that the error should be raised as a warning, but other checks would continue.
  • Most mrg_data_check_<description>() functions would have a skip_<description>=FALSE default argument to allow skipping of a test.

[kylebaron]

No objections. But I'd like to set up a set of higher level functions that give simple calls with reasonable defaults (could all be built on top of what you set out.

check_my_data(data)
# Looks good!

or

check_my_data(data)
# problems!  Let me tell you what they are