En la programación hay que siempre pensar en el caso de éxito, donde la persona hace lo que se le indica: ingresar números donde deben ir números, espacios, etc. Son cosas que uno espera de personas que interactúan entre uno mismo y las personas correctamente, pero no… no ocurre así.
En muchas interfaces humano-máquina, las personas tienden a introducir correctamente los valores cuando son preguntas discretas (edad, peso, etc.), pero en otras ocasiones, existe el problema en que no existe un formato -o máscara- de ingreso de datos, por lo cual podemos esperar cualquier formato de texto o número. Por ejemplo, pide a una persona que entregue un número de teléfono en el formato que la persona desee: es muy posible que recolectes muchas formas (más de 2 como mínimo), lo que implica que al momento de pasarlo a un sistema informático podrás tener muchas formas de expresar la misma idea.
+56-227877600
2-27877600
22-7877600
La mejor forma, sin lugar a dudas, de ingresar un teléfono
¿Cómo nos enfrentamos a eso en la informática?. Muchos informáticos -primero yo-, hacemos algoritmos pensando en el mundo ideal, es decir el usuario no comete errores, pero ¿cómo sería empezar al revés?. Si partimos pensando en validar que la cadena es errónea (es decir, el usuario no es más hábil que un mono), deberíamos plantearnos cómo esperamos el dato (por ejemplo, máscara de entrada), para luego confirmar que efectivamente estamos consumiendo los datos esperados.
Ayudemos para que todo sea más fácil
Si usamos aplicaciones webs (PWA por ejemplo), usemos los tipos de datos correctos, así todos tendremos un proceso más sencillo y expedito de validación. Hay que recordar que estas ayudas no sustituyen la necesidad de validar en el servidor, ya que eventualmente podrían inyectarnos datos duros por PostMan o alguna herramienta similar, y obviar las validaciones por parte del cliente (javascript o HTML5 nativo).
Así mismo, hay que proveer al usuario un mecanismo para saber qué tipo de dato y cómo lo estamos esperando. Por ejemplo, en el número de teléfono chileno sabemos que esperamos el +56 <código> <número de 8 dígitos>, por tanto, podemos expresar esto así:
+56
<input type="text" required pattern="[0-9]{1}">
<input type="text" required pattern="[0-9]{8}">
Con esto evitamos el problema que el formulario se envíe en un formato poco expresivo para el usuario, y cuyo significado sea coherente para nosotros. Se puede iterar para más resoluciones con Bootstrap y otras yerbas, pero en esencia, se puede mejorar para incluir más información de cómo se ingresa el contenido del campo. Eventualmente, se puede llegar a esto:
+56
<input type="text" required pattern="[0-9]{1}[-]{1}[0-9]{8}">
Para que se evite el ingreso de un prefijo teléfonico.
Ha fallado, ¿qué hacemos?, retornemos un error coherente
¿Qué ocurre si nos ingresa un dato erróneo?, debemos hacer que el código reclame correctamente y con un mensaje claro para informar este error, además de indicar severidad si es posible:
- Si es un error grave de la aplicación, una excepción (idealmente controlada)
- Si es un error leve (ingreso erróneo de dato), basta con un error o una excepción más simple para que el programa sepa que no pudo continuar su ejecución.
Sí, son dos niveles de falla ¿por qué?. Si la falla es error fatal (base de datos offline o API no autentica), la aplicación queda totalmente detenida y eso afecta a todo el proceso del usuario y todas las interacciones, mientras que un error leve, solo produce una pequeña advertencia que no afecta a la interacción de las personas con el sistema.