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

# Die 20 Regex-Muster, die ich tatsächlich benutze (nachdem ich die anderen 200 massenhaft gelöscht habe)

Ich habe einmal einen 847-Zeichen Regex zur E-Mail-Validierung geschrieben. Es hat drei Stunden meines Lebens in Anspruch genommen, die ich nie zurückbekommen werde, mit verschachtelten Lookaheads, Ausnahmen für Zeichenklassen und genug Backslashes, um mir die Augen zum Tränen zu bringen. Ich war so stolz darauf. Ich habe es in unserem Team-Slack mit einer selbstzufriedenen Nachricht gepostet: "Das behandelt ALLE Randfälle".

Dann hat mir jemand den RFC 5322 verlinkt.

Für die, die es blissfully unaware sind: RFC 5322 ist die offizielle Spezifikation für E-Mail-Adressen. Das tatsächlich vollständige Regex-Muster, das jede technisch legale E-Mail-Adresse validiert, ist über 6.000 Zeichen lang. Es beinhaltet Dinge wie Kommentare in Klammern, zitierte Zeichenfolgen mit Escape-Zeichen und Domain-Literalien in eckigen Klammern. Technisch gesehen ist `"very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com` eine gültige E-Mail-Adresse gemäß der Spezifikation.

Ich starrte auf mein 847-Zeichen-Muster. Dann auf den RFC. Dann wieder auf mein Muster. Dann tat ich, was jeder vernünftige Entwickler tun würde: Ich ersetzte es durch `/.+@.+\..+/` und machte mit meinem Leben weiter. Denn – niemand verwendet tatsächlich diese Randfälle. Und wenn sie es tun, haben sie es verdient, dass alles kaputtgeht.

Das war vor fünf Jahren. Seitdem habe ich Hunderte von Regex-Mustern geschrieben. Ich habe Regex debuggiert, das selbst erfahrene Entwickler weinen ließ. Ich habe Muster optimiert, die Produktionsverzögerungen verursachten. Und durch all das habe ich etwas Entscheidendes gelernt: Die meisten Regex-Muster sind Müll, den du nie brauchen wirst.

Meine Reise vom Regex-Maximalisten zum Minimalisten

Ich habe früher Regex-Muster gesammelt, wie manche Menschen Briefmarken sammeln. Ich hatte eine massive `regex-library.js`-Datei mit Mustern für alles Vorstellbare. IPv6-Adressen mit Zonen-IDs. Kreditkartennummern mit Luhn-Algorithmus-Validierung. URLs, die jedes obskure Protokoll verarbeiten. Sozialversicherungsnummern mit Gebietsnummernvalidierung aus den 1930er Jahren.

Die Datei war 3.200 Zeilen lang. Ich war überzeugt, ich baue etwas Wertvolles – eine umfassende Bibliothek, die mir bei jedem Projekt Zeit sparen würde. Ich hatte sogar begonnen, Dokumentation dafür zu schreiben, komplett mit Beispielen und Leistungsbenchmarks.

Dann habe ich den Job gewechselt.

In meiner neuen Firma habe ich versucht, meine geliebte Regex-Bibliothek in unseren Code einzufügen. Der Senior-Architekt warf einen Blick darauf während des Code-Reviews und stellte eine einfache Frage: "Welche davon hast du in den letzten sechs Monaten tatsächlich benutzt?"

Ich ging durch die Datei mit einem Hochlighter. Von über 200 Mustern hatte ich vielleicht 15 verwendet. Der Rest waren "nur für den Fall" Muster – Lösungen, die nach Problemen suchten. Muster, die ich geschrieben hatte, weil sie intellektuell interessant waren, nicht weil sie echte Probleme lösten.

Das war der Moment, als ich meine große Regex-Säuberung begann. Ich ging jedes Muster durch und fragte: "Habe ich das in der Produktion gebraucht? Nicht 'vielleicht brauche ich es irgendwann', sondern habe ich es tatsächlich gebraucht?" Wenn die Antwort nein war, wurde es gelöscht. Keine Gnade. Keine "aber was ist, wenn" Ausnahmen.

Die Datei ging von 3.200 Zeilen auf 400. Dann auf 200. Dann auf etwa 100 Zeilen mit 20 Mustern, die ich tatsächlich regelmäßig benutze. Und weißt du was? Ich habe die anderen 180 Muster nie vermisst. Nicht einmal ein bisschen.

Als Regex fast unsere API lahmlegte

Lasst mich euch von dem schlimmsten Produktionsvorfall erzählen, den ich je mit Regex verursacht habe. Wir hatten einen API-Endpunkt, der nutzergenerierte Inhalte akzeptierte – im Grunde ein Notizfeld, in dem die Benutzer schreiben konnten, was sie wollten. Einfach genug, oder?

Außer wir wollten URLs im Text erkennen und automatisch verlinken. Also schrieb ich, was ich für ein cleveres Regex-Muster hielt, das URLs erkennen und gleichzeitig falsch-positive Ergebnisse vermeiden würde. Es hatte Lookaheads, um die gültigen Protokolle zu überprüfen, Zeichenklassen für Domainnamen, optionale Portnummern, Pfadsegmente, Abfrageparameter und Fragmentbezeichner. Es war schön. Es war umfassend. Es war ein katastrophaler Fehler.

Das Muster funktionierte im Test gut. Ich warf verschiedene URLs darauf, und es bearbeitete sie perfekt. Ich fühlte mich ziemlich gut, als wir am Freitagnachmittag in die Produktion gingen. (Ja, ich weiß. Never deploy on Friday. Ich habe diese Lektion auf die harte Tour gelernt.)

Innerhalb einer Stunde gingen unsere API-Antwortzeiten von 50 ms auf 30 Sekunden. Dann begannen die Timeout-Fehler. Unser Monitoring leuchtete wie ein Weihnachtsbaum. Benutzer beschwerten sich. Mein Telefon klingelte. Es war schlimm.

Der Übeltäter? Ein Benutzer hatte eine lange Textzeichenfolge eingefügt, die zufällig Muster enthielt, die katastrophales Backtracking in meinem Regex auslösten. Der Regex-Engine versuchte jede mögliche Kombination von Übereinstimmungen, und bei einer 5.000-Zeichen-Eingabe bedeutete das Milliarden von Versuchen. Jede Anfrage beanspruchte einen CPU-Kern zu 100 % für über 30 Sekunden, bevor sie timte.

Wir haben sofort zurückgerollt, und ich verbrachte das Wochenende damit, dieses Muster neu zu schreiben. Die neue Version war einfacher, weniger "clever" und hatte explizite Grenzen für die Wiederholung. Es erkannte nicht jedes mögliche URL-Format – es erkannte die 99,9 % der URLs, die Leute tatsächlich verwenden. Und es lief in Mikrosekunden statt in Sekunden.

Dieser Vorfall hat mir etwas Entscheidendes beigebracht: Regex-Komplexität ist eine Belastung, kein Gewinn. Je ausgefallener dein Muster ist, desto wahrscheinlicher ist es, dass es in der Produktion schiefgeht. Einfache Muster, die gängige Fälle abdecken, sind fast immer besser als komplexe Muster, die jeden Randfall berücksichtigen.

Was wirklich zählt, aufschlüsseln

Nach Jahren des Schreibens von Regex und dem Lernen aus meinen Fehlern habe ich ein einfaches Framework entwickelt, um zu entscheiden, welche Muster es wert sind, behalten zu werden. Es reduziert sich auf drei Kriterien:

Bei Verwendung dieser Kriterien schaffen es die meisten Muster nicht durch die Prüfung. Dieses ausgefallene Regex für die Analyse von ISO 8601-Daten mit Zeitzonen-/Wochennummern? Fällt beim Häufigkeitstest durch – ich brauche es vielleicht zweimal im Jahr, und wenn ich es tue, kann ich es nachschlagen. Das Muster zur Validierung von IBAN-Bankkontonummern? Fällt beim Zuverlässigkeitstest durch – es ist so komplex, dass ich mir nicht traue, es zu pflegen. Das rekursive Muster zur Übereinstimmung von geschachtelten Klammern? Fällt beim Leistungstest durch – es ist ein Backtracking-Albtraum, der nur darauf wartet, dass er auftaucht.

Was übrig bleibt, sind Muster, die einfach, schnell und lösen Probleme, die ich regelmäßig antreffe. Es sind nicht die interessantesten Muster. Es sind nicht die, die dich clever fühlen lassen. Aber es sind die, die tatsächlich zählen.

Das beste Regex-Muster ist das, das du sechs Monate später um 2 Uhr nachts verstehen kannst, wenn die Produktion ausfällt und du versuchst herauszufinden, warum die Benutzereingabe deine Validierung bricht.

Die 20 Muster, die die Säuberung überlebt haben

Hier ist die vollständige Liste der Regex-Muster, die ich tatsächlich benutze, organisiert nach Kategorie. Das sind die Überlebenden – die Muster, die ihren Wert durch wiederholte Verwendung in realen Projekten bewiesen haben.