“There was some date-checking going on–presumably to stop you entering a year during the Black Death”

Writing good code is hard. As the old joke goes: if it were easy, everyone would be doing it. Part of writing good code is defining the use cases, the allowable input data and the expected output ranges. At the lab, we’re heavy users of conditional cell formats in Excel: define an acceptable range for a result and highlight it if it goes out of range. It may not be perfect, but it can make it obvious that something is wrong, either due to a typo or an unexpected but correct input.

Indeed, I’d go so far as to say that any sort of numerical handling in an app or spreadsheet should be liberally smothered with appropriate handling and highlighting. It should be part of the basic techniques that we learn when we start on our coding journey. I’d even say that a modern spreadsheet should start with all cells locked, and you’re only allowed to unlock cells for data entry when you have predefined acceptable ranges for the data. It might sound clumsy in a “throw it into Excel and munge the numbers” world, but you only need to look at recent handling of government Covid data (see Steve’s column on p120) to know where this ends up if you’re not careful.

Any sort of code evaluation should include such checks. This can be for code injection, buffer overrun issues and all other sorts of coding unpleasantness. But also just for the expected input range and output values