Comment 2 for bug 1818692

Evergreen really doesn't have a barcode requirement in the sense of a standard like Codabar. Those standards are used by barcodes scanners to create a string that is then passed to Evergreen. Someone could create a whole new barcode standard we've never heard of and so long as the scanner passes the string to Evergreen it is fine. The only requirements are when things happen that cause issues with parsing barcodes. So, in regards to https://bugs.launchpad.net/evergreen/+bug/1798187 the space is, for now, a bad thing (tm) though that could change based on how the regex changes. For example, if they take out the space split and start splitting on new lines only. That bug becomes messy because we're trying to guess to at the best way to clean up ugly input and no one set of rules will cover every scenario. And all the other scenarios in that bug are purely having to do with passing the barcode not it itself.

As far as actually documenting barcodes should we, in addition to saying "do not have spaces in the middle of your barcodes", also document best practices for barcodes? For example, I'd say a best practice is to limit barcodes to alphanumeric characters though that strictly isn't a requirement of Evergreen.

For example, currently '4444(333)4444' seems to work fine (based on a very brief test) but I could imagine someone using regex that doesn't escape special characters correctly and it breaking.