0

I'm writing code to clean and process a large number of transcript text files. My code will be re-used in the future to process additional files which do not yet exist.

Future files will take on the same general format as existing files, and will be collected/produced using the same procedures as were used to make the existing files. However, it remains possible that future files could violate some assumption built into my code. For example, say I write a regular expression to extract all text after the occurrence of string X, built on the assumption that X occurs only once, which holds true in the existing files. If future files violate this assumption, my code could produce unexpected/undesired results.

I am doing my best to avoid this and to make my code as robust as possible, but I don't think I can anticipate all possible scenarios that may present in future files.

Is there a term for this type or class of problem? I plan to make note of this issue to my manager (who is largely a non-programmer) when I deliver my code, and I'd like to be able to use an established term for this in order to gesture -- such as by linking to a relevant Wikipedia page or other source -- to the fact that it is (I assume) a common topic of concern when writing code for data that are not yet fully available.

Related ideas I can think of:

  • unanticipated edge cases
  • "future-proofing" code, though this is probably more general than what I'm looking for.
  • generalization error, though this is about prediction problems in machine/statistical learning, related to differences between training and test sets.
1
  • Code that tolerates unanticipated inputs is called "robust". The process of making better regex expressions, or eliminating them and using an actual parser, is "robustification". So I'd call this a "Robustification Error", or "Lack of Robustness" or similar.
    – user949300
    Commented Feb 3, 2022 at 16:03

1 Answer 1

2

If you have to make assumptions about the structure of your inputs, like the assumption that string X occurs only once, then you are dealing with an incomplete specification of those files.

When reporting to your manager, tell him that the specification for the input files is incomplete and that as a result you have made some assumptions A, B and C. Those assumptions are based on the actual input files you had available, but they may prove the be false for other, future, input files.

1
  • I will always check those assumptions, at least in a development build, and notify the developer very visibly if some input is not as expected. (I remember a story of a JSON message describing a delivery of clothes, with dress sizes stored as an integer. Except one dress was size “12/14” as a string. You better recognise that. )
    – gnasher729
    Commented Feb 3, 2022 at 20:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.