The 20 Regex Patterns I Actually Use (After Mass-Deleting the Other 200)

# Los 20 Patrones Regex que Realmente Uso (Después de Eliminar Masivamente los Otros 200)

Una vez escribí un regex de 847 caracteres para validación de correos electrónicos. Me tomó tres horas de mi vida que nunca recuperaré, completo con lookaheads anidados, excepciones de clases de caracteres y suficientes barras inversas para hacer que mis ojos lloren. Estaba tan orgulloso de ello. Lo publiqué en nuestro Slack de equipo con un mensaje arrogante: "Esto maneja TODOS los casos extremos".

Luego alguien me vinculó al RFC 5322.

Para aquellos que están felices de estar desprevenidos, el RFC 5322 es la especificación oficial de direcciones de correo electrónico. El patrón regex real y completo que valida cada dirección de correo electrónico técnicamente legal tiene más de 6,000 caracteres de longitud. Incluye cosas como comentarios entre paréntesis, cadenas entre comillas con caracteres escapados y literales de dominio entre corchetes. Técnicamente, `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` es una dirección de correo electrónico válida según la especificación.

Miré mi patrón de 847 caracteres. Luego miré el RFC. Luego volví a mirar mi patrón. Entonces hice lo que cualquier desarrollador razonable haría: lo reemplacé con `/.+@.+\..+/` y continué con mi vida. Porque — nadie usa realmente esos casos extremos. Y si lo hacen, se merecen lo que se rompa.

Eso fue hace cinco años. Desde entonces, he escrito cientos de patrones regex. He depurado regex que hicieron llorar a desarrolladores senior. He optimizado patrones que estaban causando ralentizaciones en producción. Y a través de todo ello, he aprendido algo crucial: la mayoría de los patrones regex son basura que nunca necesitarás.

Mi Viaje de Maximalista Regex a Minimalista

Solía coleccionar patrones regex como algunas personas coleccionan sellos. Tenía un enorme archivo `regex-library.js` con patrones para todo lo imaginable. Direcciones IPv6 con ID de zona. Números de tarjetas de crédito con validación del algoritmo de Luhn. URLs que manejaban cada protocolo oscuro. Números de seguro social con validación de número de área de los años 30.

El archivo tenía 3,200 líneas de largo. Estaba convencido de que estaba construyendo algo valioso: una biblioteca completa que me ahorraría tiempo en cada proyecto. Incluso comencé a escribir documentación para ello, completa con ejemplos y benchmarks de rendimiento.

Luego cambié de trabajo.

En mi nueva empresa, traté de importar mi querida biblioteca regex a nuestra base de código. El arquitecto senior echó un vistazo y hizo una simple pregunta: "¿Cuál de estos realmente has usado en los últimos seis meses?"

Revisé el archivo con un resaltador. De más de 200 patrones, tal vez había usado 15. El resto eran patrones "por si acaso": soluciones en busca de problemas. Patrones que había escrito porque eran intelectualmente interesantes, no porque resolvieran problemas reales.

Fue entonces cuando comencé mi gran purga de regex. Pasé por cada patrón y pregunté: "¿He necesitado esto en producción? No '¿lo necesitaré algún día?', sino ¿lo he necesitado realmente?" Si la respuesta era no, se eliminaba. Sin piedad. Sin excepciones de "pero ¿qué pasaría si?".

El archivo pasó de 3,200 líneas a 400. Luego a 200. Después a unas 100 líneas que contenían 20 patrones que realmente uso regularmente. ¿Y sabes qué? Nunca he extrañado a los otros 180 patrones. Ni un poco.

Esa Vez que Regex Casi Derribó Nuestra API

Déjame contarte sobre el peor incidente de producción que he causado con regex. Teníamos un endpoint de API que aceptaba contenido generado por el usuario: básicamente un campo de notas donde los usuarios podían escribir lo que quisieran. Sencillo, ¿verdad?

Excepto que queríamos detectar y auto-enlazar URLs en el texto. Así que escribí lo que pensé que era un patrón regex ingenioso que coincidiría con URLs mientras evitaba falsos positivos. Tenía lookaheads para verificar protocolos válidos, clases de caracteres para nombres de dominio, números de puerto opcionales, segmentos de ruta, parámetros de consulta e identificadores de fragmento. Era hermoso. Era completo. Fue un error catastrófico.

El patrón funcionó bien en las pruebas. Lanzé varias URLs y las manejó perfectamente. Me sentía bastante bien cuando lo desplegamos en producción una tarde de viernes. (Sí, lo sé. Nunca desplegar en viernes. Aprendí esa lección de la manera difícil.)

En menos de una hora, nuestros tiempos de respuesta de API pasaron de 50 ms a 30 segundos. Luego comenzaron a ocurrir timeouts. Nuestro monitoreo se iluminó como un árbol de Navidad. Los usuarios se quejaban. Mi teléfono sonaba. Fue malo.

¿El culpable? Un usuario había pegado una larga cadena de texto que contenía patrones que activaban retrocesos catastróficos en mi regex. El motor regex estaba intentando cada combinación posible de coincidencias, y con una cadena de entrada de 5,000 caracteres, eso significó miles de millones de intentos. Cada solicitud estaba utilizando un núcleo de CPU al 100% durante más de 30 segundos antes de que se produjera un timeout.

Retrocedimos de inmediato, y pasé el fin de semana reescribiendo ese patrón. La nueva versión era más simple, menos "ingeniosa" y tenía límites explícitos en la repetición. No atrapaba todos los formatos de URL posibles; capturaba el 99.9% de las URLs que la gente realmente usa. Y corría en microsegundos en lugar de segundos.

Ese incidente me enseñó algo crucial: la complejidad de regex es un pasivo, no un activo. Cuanto más elegante sea tu patrón, más probable es que te muerda en producción. Los patrones simples que manejan casos comunes son casi siempre mejores que los patrones complejos que manejan cada caso extremo.

Desglosando Lo Que Realmente Importa

Después de años de escribir regex y aprender de mis errores, he desarrollado un marco simple para decidir qué patrones valen la pena conservar. Se reduce a tres criterios:

Usando estos criterios, la mayoría de los patrones no pasan la prueba. ¿Ese regex elegante para analizar fechas ISO 8601 con compensaciones de zonas horarias y números de semanas? No pasa la prueba de frecuencia: lo necesito tal vez dos veces al año, y cuando lo hago, puedo buscarlo. ¿El patrón para validar números de cuenta bancaria IBAN? No pasa la prueba de fiabilidad: es tan complejo que no confío en mí mismo para mantenerlo. ¿El patrón recursivo para coincidir con paréntesis anidados? No pasa la prueba de rendimiento: es una pesadilla de retroceso esperando a suceder.

Lo que queda son patrones que son simples, rápidos y resuelven problemas que encuentro regularmente. No son los patrones más interesantes. No son aquellos que te hacen sentir ingenioso. Pero son aquellos que realmente importan.

El mejor patrón regex es el que puedes entender seis meses después a las 2 AM cuando la producción está caída y estás tratando de averiguar por qué la entrada del usuario está rompiendo tu validación.

Los 20 Patrones que Sobrevivieron a la Purga

Aquí está la lista completa de patrones regex que realmente uso, organizados por categorías. Estos son los sobrevivientes: los patrones que demostraron su valía a través del uso repetido en proyectos reales.