Too much validation

[pne]

I tried to transfer some money online just now.

However, the bank's form didn't like the copy-and-pasted account number, saying that "no special characters, spaces, or letters are allowed".

Why can't the field simply allow (and ignore) spaces? It's certainly wide enough.

Strangely enough, the bank sort code field happily accepted the number with spaces in the usual "123 456 78" form. (It didn't always; the field used to be limited to eight characters so if you copy-pasted a normally-formatted sort code, the last two characters got lopped off.)

I wonder what would be so bad about allowing spaces in the bank account number.

Comments

[kait-the-great.livejournal.com]

It's probably stored/handled as a number, which really couldn't be processed with spaces.

Personally, I think that's a bad practice. There are some older student numbers at my uni which start with two leading zeros, making it a particularily bad field to store with an int, for example.

[darth-spacey.livejournal.com]

It's a surprisingly annoying task to programmatically decipher free text that may or may not be the data you're expecting. It remains a sad fact that intelligence is not equitably distributed among the population, and if you don't put a decent amount of the burden of formatting the data on the user, you can easily end up accepting wildly inaccurate data. People will, unfortunately, enter just about anything in any format into a form unless carefully and explicitly guided on how to do things correctly.

Even the task of writing an expression that accepts every valid email address, and no invalid email addresses, is pretty substantial -- even only according to syntax. Any kind of lexical testing on top of syntactic testing becomes effectively computationally impossible in the general case.

[bride.livejournal.com]

Legacy. There are still banking systems that were created long long ago that were written in COBOL, FORTRAN or whatever the hot programming language was in the Mesozoic era.

I know that sometimes, somewhere along the line, we have to interface with WANDA (Bank of America) to transfer funds to and fro. This system cannot accept spaces or dashes in the Account Numbers, IBANs or special characters in the Beneficiary Name.

We debate this around and around every time it comes up. Should we strip the dashes and spaces? Some say yes, because that's what the legacy systems expect and the end user should be able to enter it as they see it. Some say no, because that's not what the end user entered so we must maintain the integrity of the data that the end user entered.

We allow the spaces and dashes. But they have to be cleaned up manually before the payments can be sent through to WANDA.

It causes a lot of data issues now that we're trying to migrate data from a legacy system to a new system. You need to allow the end user to enter account numbers and long strings of numbers with dashes or spaces because that's exactly what the user transcribes from some other reference information. Those spaces and dashes were put in to minimize human error, but cannot be in the data sent to the legacy systems.

Yes, the systems should handle it. But as a part of field validation, it's easiest to just not allow the user to enter dashes and spaces to begin with so you can be sure of what inputs you're getting. And when you're pressed for time on projects, that's one of the first time cutting decisions to be made.

[pne.livejournal.com]

Wait... they store bank account numbers as an integer?

That would just sound silly to me.

A guideline I once heard was "Use a numeric field if you intend to to calculations with it. Otherwise, use a character field, even if you expect to get only digits." That would cover not only bank account numbers but also e.g. postal codes (which can start with 0 in the US or -- since 1990 or so when they switched from four digits to five -- Germany), or even employee ID numbers.

But on the other hand, even if they did store it as an integer, there's nothing preventing them from accepting spaces or slashes and simply stripping them from the input before converting the remainder to a number; that's a simple matter of programming, so why make a human do the work of preprocessing that a machine can do? After all, I don't expect them to echo back the exact input I gave them; if they want to normalise it to "digits only; no spaces, hyphens or dashes; leading zeros suppressed (or left-padded with zeroes to n places)", that's fine with me.

[pne.livejournal.com]

Even the task of writing an expression that accepts every valid email address, and no invalid email addresses, is pretty substantial

I saw one that attempted to (though it only handled one level of recursion in comments, IIRC) in Friedl's Mastering Regular Expressions.

But I'm not sure whether it's that useful; for one, it's really long, and for another, the allowable formats for an email address are rather broader than many people expect. For example, off the top of my head,

   Philip    . (Christopher) Newton @ gmail (or googlemail - either works) .com  

is a valid email address, though most systems probably wouldn't be ale to handle it correctly due to the spaces and comments.

[kait-the-great.livejournal.com]

That's what you would expect from a good design, and so since they aren't doing any automated stripping, then they aren't using a good design, so it's not out of the question that they are using a number.