Blog post on input checking

[Bisaloo]

Fix #149.

All comments are welcome and I'm ready go through as many review rounds as necessary to reach the required quality for publication.

[maelle]

Thanks so much Hugo et al! Excellent input quality! 😉 I've made a few comments.

[pearsonca]

Pasting from internal slack conversation:

Overall seems fine. The particular issues that I don't see addressed (which reflect my somewhat curmudgeonly / luddite / high-expectations-for-users disposition):

• absolutely first and foremost: document what the arguments are supposed to be. Telling the user what to provide is the first line of defense against them giving your code something stupid and first recourse to answer their questions about what went wrong when they still do.
• I think there's more to say on the base R component. as argued in earlier slack thread: there's a balancing act here amongst competing s.e. principles: minimize dependencies, don't prematurely optimize, and DRY. Base R also offers other useful checking functions (match.arg e.g.). The appropriate error checking approach should be guided by what you're doing (both in the particular code and as a general habit)
• think about the audience and what else you've done. again, if the arguments are documented with expectations (#' @param name, a non-empty, non-NA character scalar), then stopifnot(!missing(name), is.character(name), length(name) == 1, !is.na(name), name != "") + the documentation is sufficient for general developers & sophisticated users, but maybe not novices and only-occasional-programmers
• the fancy packages are mostly just convenience wrappers around the base R functionality to save you key strokes. that's fine and useful, but don't expect it to miraculously disappear complicated mutual constraints within and between complex input objects
• in your closing paragraph, possibly worth noting that a big chunk of input validation here is because R doesn't have robust support of "type" like compiled languages (c++, e.g.). if your user-facing code is quite small, but there's lots of internal machinery that you're doing all sorts of input validation on to keep bugs from crawling in as you make changes, might be another note in favor of switching those internals to compiled code so that the compiler provides the guarantees

an aside probably not for the R audience, but in the more complex languages, the general problem of input validation is often called contracts or predicates and is being considered for sophisticated analysis even in older languages like c++ (https://www.reddit.com/r/cpp/comments/cmk7ek/what_happened_to_c20_contracts/ - though obviously not yet successfully) - though notably that concept also includes an element about the properties of results of a function, so is somewhat integrating unit-testing-like features more directly into code

[Bisaloo]

@TimTaylor, could you please review this and add an author file? https://github.com/r-hub/blog/tree/master/content/authors. I invited you as an external collaborator to the fork in epiforecasts but you can also post the content in a comment here.

[maelle]

I'm reviewing the post but to answer

@maelle, what is your opinion on this?

Maybe part of this could be worked into the conclusion?

[maelle]

Very cool, thank you! Less comments this time :-)

[maelle]

Thanks so much! I feel very nitpicky with my very last comments.

I really like the section about no approach being the best one.

[TimTaylor]

Hi @Bisaloo, apologies I've only had time to do a quick gander. If not too late in the day I think {vetr} is definitely worth a mention in the alternatives. They also provide a good comparison of different packages which would be worth highlighting.

[pearsonca]

Hi @Bisaloo, apologies I've only had time to do a quick gander. If not too late in the day I think {vetr} is definitely worth a mention in the alternatives. They also provide a good comparison of different packages which would be worth highlighting.

@TimTaylor wow, thanks for highlighting vetr. I really like their concept; also seems to like it could dovetail well with unit testing practices - e.g. deriving template objects from the example objects used in testing (or vice versa).