2013/07/23

Codes: Things some developers never learn

I am wondering why obvious best practices get ignored so often.

I am talking for example about serial numbers & codes. Whether it be windows serial numbers, Steam codes, Nintendo Club pins or codes from iTunes some of those are ignoring obvious solutions to common problems.

Lets take a look at a sample code:

             ABlO-XY12-ZU80-I1lO-4354

Note that a lot of characters can't simply be identified. Is it a one, "L" or "i"? No one knows. The obvious solution? Do not use "L", "I" or 1's in your codes. Its as simple as that. Do not use "O" like in "Order" and zeros. (Feedback from readers: do not use S, Z, 5, and Q either). Even if your printer promises they can be distinguished at some print run its being ignored and your users can't.

And: ignore upper and lower case entries, treat input as identical. PLEASE.

Besides those obvious errors the entry of the codes in your input field can be optimized as well. Why in hell can't I copy/paste some serials with multiple code sections like above into an input field with 5 separate fields? Because it all pastes into the first field, ignoring the other 4. They don't carry over. Its not really hard to do.

Also: the last digits is a check sum. This check sum does NOT check the code server side for validation, it is to check client side if the USER did an error. Server side validation is always against a database so your codes can't be cloned.

It is not hard to do codes correct. So whenever you are involved in a project where codes are either for licensing, installation, or bonus codes please follow the simple rules above. It makes your live easier, less support tickets and less frustrated customers.

p.s.: A co worker pointed out rightly that the statements above might say that the serial number check sum client side is all you need. This is of course wrong, the check has to be made server side all the time. The check sum I meant is the user input check so at least the basic serial is correct and not gibberish. That can be client side. However exposing your check sum method in the client isn't wise either. Maybe we need two.


1 comment:

  1. Our codes *almost* got it right. I remember going over this and agreeing on it, but the end result codes had 0 and I in them. I said I thought we agreed to not have them, but they said "it's ok we don't have l or O". :P

    ReplyDelete