Cuándo no usar regex: tres casos clave

Saber cuándo no usar regex es tan importante como dominar la sintaxis. Antes de escribir más expresiones regulares, conviene reconocer los tres tipos de problema donde regex es la herramienta equivocada, porque identificarlos a tiempo te ahorra horas de mantenimiento y código imposible de leer.

La idea central es simple: las expresiones regulares brillan en tareas específicas, pero se rompen en escenarios que parecen encajar y no lo hacen. Vamos a ver cuáles son y por qué conviene esquivarlos.

¿Por qué regex falla con estructuras anidadas como HTML o JSON?

El primer caso donde regex deja de servir son las estructuras anidadas: HTML, XML y JSON [0:15]. Estos formatos funcionan como cajas dentro de cajas, y ahí está el problema.

Una expresión regular se lee de izquierda a derecha, sin contar necesariamente con esa profundidad. Imagina que tienes una etiqueta dentro de otra idéntica y pides el texto desde el primer inicio hasta el primer cierre. El motor se detiene en el cierre interno y deja la mitad del contenido por fuera.

¿Por qué no puedo parsear HTML con regex? Porque el HTML es jerárquico, como cajas dentro de cajas, y regex lee en línea recta. El motor se detiene en el primer cierre que encuentra y rompe el contenido anidado.

La solución es usar las librerías de tu lenguaje, que ya están optimizadas para esto [0:44]. Ellas analizan el documento como un árbol, no como una línea recta.

¿Sirve regex para validar la existencia de un email?

El segundo caso es intentar validar la existencia real de algo. Mucha gente busca la fórmula perfecta con regex para validar un correo, pero el formato no es lo mismo que la existencia [1:03].

Una expresión regular te dice si un email está bien escrito, pero nunca te dirá si el buzón existe o si el usuario se inventó los datos. En la práctica, solo verificas la estructura básica: un arroba, un punto.

¿Regex puede confirmar si un correo existe? No. Regex solo valida el formato, es decir, que tenga arroba y punto. La existencia se confirma con un paso extra, como enviar un correo de verificación o un SMS.

Esto aplica igual para teléfonos, direcciones web y más. Confirmar lo real siempre requiere un paso extra que debes integrar, como un SMS o una pasarela de pago [1:37].

¿Cuándo conviene una función de texto en vez de regex?

El tercer caso es buscar texto fijo sin variantes. Si tu problema no tiene condiciones variables, hay funciones nativas más rápidas y legibles [1:47]:

• Si solo quieres saber si una línea empieza con error, usa la función Empieza con.
• Si quieres saber si un párrafo contiene admin, usa Contiene.
• Si quieres cambiar una palabra fija por otra, usa un reemplazo directo.

Las funciones nativas son más rápidas y cualquiera puede entender tu código al verlo. Si no hay condiciones variables, no hace falta una expresión regular.

¿Qué tres preguntas debo hacerme antes de usar regex?

Antes de escribir una expresión regular, hazte estas tres preguntas [2:12]:

1. ¿Tiene estructura de cajas anidadas? Si sí, usa una librería especializada.
2. ¿Necesito validar la existencia real de algo? Utiliza otro servicio.
3. ¿Lo resuelve una función de texto básico? Vete por el camino simple.

Si un problema pasa las tres pruebas, entonces sí tiene sentido usar una expresión regular. Es un filtro rápido que te evita complicarte de más.

¿Por qué regex sí funciona para procesar un log?

Y aquí viene lo interesante: el log que trabajamos a lo largo del curso pasa las tres preguntas [2:40]. No es jerárquico, son líneas planas. Tampoco se encarga de validar que los datos pertenezcan a un servidor, porque de ahí solo queremos extraer y ordenar información.

¿Se puede resolver acortando espacios? Veamos con un ejemplo concreto. Cuando la acción de Laura dice action search query, si cortamos por espacios tendríamos dos acciones separadas: search y query [2:55]. Pero en realidad es una sola acción, y al separarlas se arruina todo.

Ahí es donde las expresiones regulares se vuelven una ventaja real para lo que estamos haciendo. El caso encaja perfecto porque no hay anidamiento, no validamos existencia y una función simple no basta.

Ahora sabes que parsear un HTML o validar emails complejos casi siempre requiere otra herramienta, y que validar el formato no es validar existencia. Con esto claro, el siguiente paso es lo fundamental de regex: emparejar texto literal y los caracteres con poderes especiales. ¿Se te ocurre algún caso donde dudarías entre regex y una función nativa? Cuéntalo en los comentarios.