Diesem Paradigma folgende Lösungen können selbst dann gut funktionieren, wenn sie auf den ersten Blick absurd wirken: Die Frage Was ist der Vorname von Franz Beckenbauer? schützt gegen spam nämlich genau so gut wie ein komplexes Analyse-plugin. Auch die Methode der Riesenmaschine, neue Kommentare gegen eine kurze Liste unerwünschter Wortbestandteile (etwa !!, lugschei) zu prüfen, kommt ohne komplizierte Filtermodelle aus.

Wie es hingegen nicht geht, beschreibt Lea Verou anhand der Aufgabe, das Doppelkreuz am Anfang von URL-Fragmenten zu entfernen. In einem Buch fand sie dazu den JavaScript-Schnipsel location.hash.match(/#(\w+)/)[1]. Der enthält allerdings nicht nur einen unleserlichen regulären Ausdruck, sondern funktioniert auch nicht; so produziert die Verarbeitung des gültigen Werts #♥ einen Fehler. Verous in jedem Fall funktionierende Alternative lautet schlicht location.hash.substring(1).

Um Fehler dieser Art zu verstehen, sollte man wissen, dass viele Programmierer nicht programmieren können. Damit ist nicht gemeint, dass sie unfähig sind, lauffähigen Code zu produzieren – sie haben jedoch Schwierigkeiten, ein zutreffendes mentales Modell der Programmlogik zu entwickeln. Hinzu kommt mangelnde Lesekompetenz: So lehnen Programme etwa Email-Adressen mit Plus-Zeichen ab, weil die Entwickler nicht wissen, welche Zeichen erlaubt sind – und dennoch überzeugt sind, das Richtige zu tun.

Dass jemand einen Algorithmus oder eine Spezifikation missverstanden hat, ist jedoch für Außenstehende nicht auf den ersten Blick erkennbar, für einen selber sogar noch weniger. Unabhängig vom Ego gilt aber: Programme nach dem Simplest Thing-Prinzip zu schreiben reduziert das Risiko, etwas Unverständliches zu produzieren – selbst für jene, die sich für besonders clever halten. Als Fingerübung habe ich mir daher vorgenommen, so weit wie möglich auf reguläre Ausdrücke zu verzichten.

The Simplest Thing that Could Possibly Work muss übrigens nicht unbedingt aus eigenem Code bestehen: Spezialisierte Programmbibliotheken zu nutzen spart nicht nur Zeit, sondern reduziert ebenfalls die Fehlerrate. Faustregel: Wer komplexe Formate wie HTML parsen oder generieren möchte, sollte besser existierende Werkzeuge benutzen, als sich selbst Gedanken zu machen – sonst besteht das Risiko, eine beherrschte Technik in einem Bereich anzuwenden, für den sie vollkommen unpassend ist (Patch für Negativ-Beispiel).

Gleich doppelt beleuchtet diese Kategorie BozoCrack – ein Programm, das mit MD5 unkenntlich gemachte Passphrasen nicht selbst knackt, sondern Google bemüht (danke, plomlompom): Es benutzt nicht nur eine externe Resource, sondern zeigt auch, dass die MD5 nutzenden Entwickler nicht verstanden haben, wie Passwörter gespeichert werden sollten.

Additionally, users are stupid: While according to RFC 3986, chevrons should be used to designate URIs, often people use parentheses. When developers try to compensate for this, they create undesired – and more than often unexpected – behaviour: Links created from perfectly valid URIs are suddenly broken – see, for example, the chat client Gajim (and also the bugtracker / wiki Trac).

According to RFC 3986, subsection 1.1.1 , URI[s] begin[s] with a scheme name, which, according to subsection 3.1 consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus (“+”), period (“.”), or hyphen (“-“). Therefore, the correct regular expression for a scheme name is [A-Za-z][A-Za-z0-9\+\.\-]* .

After the scheme name, a colon (“:”) follows – the rest is scheme-specifix synthax; according to sections 2.2 and 2.3 we only know it uses a limited set of characters, namely those reserved for delimiting data (“:”, “/”, “?”, “#”, “[“, “]”, “@”, “!”, “$”, “&”, “‘”, “(“, “)”, “*”, “+”, “,”, “;”, “=”) and unreserved ones, which include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde. This extends the regular expression to [A-Za-z][A-Za-z0-9\+\.\-]*:[A-Za-z0-9\.\-_~:/\?#\[\]@!\$&'\(\)\*\+,;=]+ – metacharacters (“[“, “\”, “$”, “.” “?”, “*”, “+” “(“, “)”) and the range specifier (“-“) properly encoded, of course.

“But wait”, you may be thinking right now, “how can I include other characters – umlauts, for example – in URIs, then ?” Well, you can’t. But you can describe a resource that contains characters not listed in the above paragraph by means of percent-encoding, a method detailed in section 2.1 to represent a data octet in a component when that octet’s corresponding character is outside the allowed set or is being used as a delimiter of, or within, the component. A percent-encoded character takes the form of a percent character (“%”), followed by two hexadecimal digits – the space character, for example, is encoded as “%20″. This gives us the expression %[A-Fa-f0-9]{2} , which can be added to the existing URI matching expression: [A-Za-z][A-Za-z0-9\+\.\-]*:([A-Za-z0-9\.\-_~:/\?#\[\]@!\$&'\(\)\*\+,;=]|%[A-Fa-f0-9]{2})+ will catch any valid URI (and probably some invalid ones too).

Now, what about the parenthesis problem that surfaced in the beginning ? A simple solution is just to define an additional expression that matches on URIs, but only if they are preceeded by an opening parenthesis (this feature is called “positive lookbehind”) and followed by a closing parenthesis (“positive lookahead”). We get (?<=\()[A-Za-z][A-Za-z0-9\+\.\-]*:([A-Za-z0-9\.\-_~:/\?#\[\]@!\$&'\(\)\*\+,;=]|%[A-Fa-f0-9]{2})+(?=\)) . Combining the two massive expressions by means of a simple OR yields the final result: ((?<=\()[A-Za-z][A-Za-z0-9\+\.\-]*:([A-Za-z0-9\.\-_~:/\?#\[\]@!\$&'\(\)\*\+,;=]|%[A-Fa-f0-9]{2})+(?=\)))|([A-Za-z][A-Za-z0-9\+\.\-]*:([A-Za-z0-9\.\-_~:/\?#\[\]@!\$&'\(\)\*\+,;=]|%[A-Fa-f0-9]{2})+) .