Con la popularización de los frameworks, código encapsulado y scripts pre-hechos que hacen la tarea de programar un poco menos tediosa, llegó también un efecto inesperado: la sobre-validación. Permítanme explicar qué es esto.

En el desarrollo web, una de las tareas más talacheras es la de validar el input que hacen los usuarios a través de formularios. Tienes que asegurarte de que el usuario haya escrito bien su correo por ejemplo, sin caracteres especiales, con sólo una arroba y muchos otros detalles que aseguran que sea un correo válido. En el caso de un código postal puedes validar que sólo haya escrito números, y que un teléfono tenga cierto número de dígitos. El código bien escrito abstrae la programación a tal punto que es suficiente especificar que un campo es de tipo email para que haga toda la validación tras las cortinas sin que te tengas que preocupar por meterle mano al código. Con la facilidad de validar tan estrictamente todos los campos, ahora hasta mi abuela puede hacer un formulario a prueba de balas.

El problema es que el mundo es muy heterogéneo. Algunos scripts validan que un nombre no contenga números. Así que si al Papa Benedicto XVI se le ocurre escribir su nombre como Benedicto 16 le rechazaríamos su solicitud. Otras mentes débiles diseñan sus bases de datos como en los tiempos donde el espacio en disco duro valía su peso en oro. Créanme, llamándome Mark John Cuauhtémoc MacKay Ávila me lo tomo muy personal cuando un estúpido formulario me dice que mi ridículo nombre es demasiado largo --sé que lo es-- pero no por eso lo tengo que mutilar.

Pero aún más débiles son las mentes que diseñan código pensando que sólo en EEUU existe eso a lo que llaman la supercarretera de la información. Seguramente más de uno de ustedes ha tenido que decir que vive en Hawaii o Texas para pasar por un formulario, o dejar un teléfono incompleto porque el diseñador/desarrollador no consideró que podrían necesitar la clave de tu país para comunicarse contigo.

Algunos errores comunes en la sobre-validación de formularios:

  • Tratar de convertir el teléfono en un número entero: la mayoría del código para validar un número telefónico intenta quitar los caracteres alfanuméricos para dejar un número entero en la base de datos. Esto es completamente innecesario a menos que uses una máquina para llamar automáticamente a tus clientes. "+052 (555) 555-5555 Ext. 302" es mucho más útil para la persona que va a hacer la llamada.
  • Asumir que un código postal sólo se puede componer de números: en Argentina, Canada, Holanda, Inglaterra y Venezuela, entre otros; los códigos postales contienen letras y números. En Irlanda, Hong Kong, Panamá y Vietnam ni siquiera existen. Así que si requieres un código postal le estarás cerrando la puerta a usuarios de estos países.
  • Sobre-validar un formulario de contacto: un formulario de contacto generalmente llega a un correo. Normalmente, si tratas de meter un un dato inválido a una base de datos (digamos una cadena demasiado larga), la base de datos va a tronar. En el correo electrónico no existe esta limitación, además hay una persona que que puede interpretar mucho mejor lo que el usuario escribió (como en el ejemplo donde se incluye la extensión en el campo de teléfono).
  • Pedir al usuario que escriba las cosas como a la base de datos le gusta: hace unos días traté de consultar mi CURP pero el formulario me lo rechazó porque no le gustaron mis acentos. Lo que el programador debió de haber hecho es remplazar los caracteres acentuados por no-acentuados. Lo mismo sucede con las fechas, frecuentemente se nos pide escribir las fechas con formato mm/dd/yy (formato anglo), pero un calendario que escriba la fecha por ti es más sensible.

Pero lo más importante de todo es: no trates de educar al usuario cómo debe de introducir los datos, el servidor deberá primero tratar de interpretar los datos, y si no encuentra qué hacer con ellos, amablemente deberá disculpar su estupidez y pedirle al usuario que lo introduzca de nuevo en un formato que sí entienda.