Robust Inputs

Robust software can handle a wide variety of circumstances without breaking down in unexpected ways. Of course, some input must be considered invalid. Robust software must then have the ability to parse diverse formats of input, and if those inputs cannot be parsed, it must have the ability to report a descriptive error. Whether or not the input can be considered invalid depends on if that input can be unambiguously matched to the Information that it was intended to represent.

Ambiguity of inputs

Ambiguous input may be reasonably interpreted as representing several distinct outcomes of data. A simple example is that of a credit card number with 17 digits. Presumably, one of the digits must be wrong, but there is no way to know which one, and so the input may be associated with 17 different credit card number—one for each digit that could be removed. A 15 digit number has even more interpretations. If we may add a new digit with ten options at one of 16 locations we get 160 possible interpretations.

You could say that a 15 digit credit card number has no possible interpretations, and this is often how invalid input is treated, but there is merit to the opposite viewpoint. An 19 digit credit card number would be considered invalid, but a 16 digit credit card number with three hyphens every 4 digits should be considered valid, as there’s only one number it may be associated with. In this sense, an empty input could be associated with every possible outcome.

Ambiguity is dependent on the relevance of information. The hyphens aren’t relevant to a credit card number, and so their inclusion or exclusion is irrelevant to ambiguity. When considering which inputs you should or should not reject, consider the mechanical relevance of the information being provided. Parenthesis and hyphens are not relevant to a phone number, as evidence by their exclusion while dialing, and so their inclusion should not cause an input to be rejected, as the number 7635553503 and (763)203-3503 are clearly the same number.