Home > General > Validation – How far would you go?

Validation – How far would you go?

January 20, 2010 Leave a comment Go to comments

I recently read a discussion on validation of user inputs. The example used was of validating the Date of Birth a.k.a DOB field. The programmer was adventurous and wanted to put validation such as

  • If DOB is more than 120 years ago, message: “You cannot be that old!!!”
  • If DOB is in the future, message: “You must be kidding, you are not born yet!!!”

His basic question was on how far would you go in validating a user input?

My view is to put minimum validation at the field level. For this example the developer can check whether it is valid date or not but that’s it!!

One can always put all the necessary validation at the form level. By doing this, most of the business logic is at one place & not divided across various fields.


Also, avoid showing ugly error messages while the user is typing. If the validation is to be done at the field level then provide hints / suggestions to the user by showing text next to his input.


We always want correct and valid data in our databases but at the same time we should not act like a policeman slapping the user for every mistake he/she makes.

So, in your next project, how far would you go in validating user inputs?

  1. January 29, 2010 at 1:27 pm

    Just playing the devil’s advocate here, let’s agree that most folks don’t live to be a 100 but what if the one user in the entire world who is 120 and a multi-billionaire comes along. Do you really not want his business?

    On a more serious note, shouldn’t ones validation code be based on and driven by what the user needs? Hopefully in the real world the project’s Requirements Analysis covers this aspect, as well as the requirement for training users who will be using your cool new software. In which case certain classes of trivial error checks can be eliminated.

    Further, if you perform minimum validation then do you make sure your code can handle ANY input? If you do not then this could be the source of specific types of security vulnerabilities.

    Moving beyond code, shouldn’t your design already include using reusable components for common actions like validating age and email-Ids. In other words for most of the sample fields in the example you really shouldn’t be writing any code.

    In fact email validation becomes a critical piece for say a Bank’s website where this email could be used for password reset requests or confidential queries. Some banks have even done away with using email ids altogether and use a system within their website for communication, only using external email ids for notification to the user that a response is waiting for them on the Banks website.

    In other words data validation can be serious business depending upon the business you are serving.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: