Ich las einst in grauer Vorzeit in einem Forum einen Thread namens Code Horrors
, wo die Mitglieder – allesamt Nerds der Oberklasse – davon berichteten, was ihre unfähigen Kollegen so für horrenden Programmcode verbrechen. Ich fand das teilweise nicht unlustig und dachte ich mir, das kann ich auch. Es folgen drei Beispiele, über die ich in jüngster Zeit gestolpert bin.
$foo[$bar[$bla[$blub]][$gna[$wtf][$unf][$foo]][$bar]]
Ich habe mal jemanden angeheuert, der mir ein Script zur Verarbeitung von Formulardaten gebaut hat. Das ist das das Herzstück seines Werks:
for($x=0;$x<count($_POST['option']);$x++)
{
if(is_array($_POST['option'][$keysx[$x]]))
{
$keysy = array_keys($_POST['option'][$keysx[$x]]);
$body = $body.$inhalt['linestart_part'].$fieldnames[$keysx[$x]][0].$inhalt['lineend_part'];
for($y=0; $y<count($_POST['option'][$keysx[$x]]); $y++)
{
if(!$_POST['option'][$keysx[$x]][$keysy[$y]])
break;
if(is_array($_POST['option'][$keysx[$x]][$keysy[$y]]))
{
$keysz = array_keys($_POST['option'][$keysx[$x]][$keysy[$y]]);
for($z=0; $z<count($_POST['option'][$keysx[$x]][$keysy[$y]]); $z++)
{
if(!$_POST['option'][$keysx[$x]][$keysy[$y]][$keysz[$z]])
break;
if(is_array($fieldnames[$keysx[$x]][$keysy[$y]][$keysz[$z]]))
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]][$keysy[$y]][$keysz[$z]][$_POST['option'][$keysx[$x]][$keysy[$y]][$keysz[$z]]].$inhalt['linemid_value'].''.$inhalt['lineend_value'];
else
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]][$keysy[$y]][$keysz[$z]].$inhalt['linemid_value'].$_POST['option'][$keysx[$x]][$keysy[$y]][$keysz[$z]].$inhalt['lineend_value'];
}
}
else
{
if(is_array($fieldnames[$keysx[$x]][$keysy[$y]]))
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]][$keysy[$y]][$_POST['option'][$keysx[$x]][$keysy[$y]]].$inhalt['linemid_value'].''.$inhalt['lineend_value'];
else
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]][$keysy[$y]].$inhalt['linemid_value'].$_POST['option'][$keysx[$x]][$keysy[$y]].$inhalt['lineend_value'];
}
}
}
else
{
if(is_array($fieldnames[$keysx[$x]]))
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]][$_POST['option'][$keysx[$x]]].$inhalt['linemid_value'].''.$inhalt['lineend_value'];
else
$body = $body.$inhalt['linestart_value'].$fieldnames[$keysx[$x]].$inhalt['linemid_value'].$_POST['option'][$keysx[$x]].$inhalt['lineend_value'];
}
}
Mir ist relativ rätselhaft was da vor sich geht und richtig verständlich machen konnte es mir der Verantwortliche auch nicht. Aber zugegebenermaßen funktioniert es … wenn auch nicht in Form eines Plugins oder einer Funktion! Nein, wir fügen einfach irgendwo im CMS-Core ein Include für die Datei mit dem obrigen Code ein, so dass der gesendete Formularinhalt abgefangen und verarbeitet werden kann. Seitdem nagele ich Programmierer vertraglich auf gewisse Mindeststandards fest.
Das Bild vom FTP-Server
Ein Kollege fragte mich mal, wie es denn sein könnte, dass in der Seite eines seiner Kunden plötzlich viele Iframes und Javascript-Blöcke sitzen, die er da sicher nicht eingebaut hatte. Diese Zusätze waren eindeutig das Werk von Crackern, die sich wohl erhofften, ein paar Passwörter oder ähnliches abzugreifen. Nur wie kam der Code in die Seite beziehungsweise in die Template-Daten? Ich muss zugeben, dass es ganz schön lange gedauert hat, bis ich in einer anderen Datei das hier fand:
<img alt="Neues Angebot 2008 - 2009" src="ftp://webuser4194808:r4987E12ue@kunden-website.net/pics/Neu_August_2008/IMG_6204.JPG">
Das hatte da sein Kunde da eingefügt.
Doppelt und geXMLt hält besser
Ich habe eine MODx-Website von jemandem geerbt, der ganz offenbar meinte, er wüsste besser als die MODx-Entwickler wie man ein CMS aufzieht. Warum er dann trotzdem MODx als Basis für seine Seite benutzte, entzieht sich meiner Kenntnis. Jedenfalls ist die Tabelle modx_site_content
leer. Wir reden hier von einer zweisprachigen Website mit ca. 100 Unterseiten.
Die Inhalte befinden sich in der Tabelle docs
mit 448 Datensätzen. Wir reden hier immer noch von einer Website mit insgesamt ca. 100 Unterseiten. Die Tabelle enthält neben der ID eine Spalte namens docId und einer Spalte namens Inhalt. Diese beinhaltet den Inhalt in beiden Sprachen, und zwar in Form von XML-Daten. Und dann gibt es noch die Tabelle lang
. Die enthält ebenfalls die Inhalte, genau die gleichen, allerdings nicht in einer Spalte als XML sondern anständig in zwei Spalten, getrennt nach Sprachen. Verknüpft werden beide Tabellen über die docId.
Warum das so ist, weiß ich nicht mit Sicherheit. Ich nehme meistens an, dass die XML-Dateien den von meinem Vorgänger eigens für das CMS programmierten WYSIWYG-Editor befüllen, während die normalen Daten das CMS füttern. An dem Editor ist außerdem interessant, dass dessen Javascript im Whitesmiths-Stil gehalten ist. Ich arbeite seit Herbst letzten Jahres mit der Seite, repariere alle paar Wochen Dinge oder baue Erweiterungen ein. Ich habe bis heute nur eine vage Vorstellung davon, wo die anderen Daten der Seiten (Titel, Elterndokument etc.) gespeichert sind.
Falls Ihr auch ein paar unterhaltsame Beispiele für anderer Leute Code habt, raus damit! Mehrzeiligen Code bitte irgendwohin auslagern (hier hin z.B.), weil in den Kommentaren <pre>
nicht funktioniert und unformatiert doof ist.
Kommentare (14)
Marc ¶
1. März 2009, 00:51 Uhr
Das MODx-Beispiel ist natürlich geil (die anderen auch, keine Frage). Ich könnt emir gut vorstellen dass da jemand den Begriff Content Management Framework so verstanden hat, dass er die Daten des Vorgänger-CMS irgendwie in MODx gepresst hat. Falls das eine komplett neu aufgesetzte Seite war, ist die Herangehensweise zumindest ungewöhnlich.
Nico ¶
1. März 2009, 00:56 Uhr
Das Letze ist echt Merkwürdig, wobei ich beim ersten auch nur einen Komischen wirr warr erkenne, und zum zweiten das ist einfach nur zum lachen :)
Das Ein zigste was ich jetzt wüsste wär der hier http://nopaste.php-quake.net/166853 bzw hab noch mehrere in der Art :D Sag aber lieber nicht wo her sonst krieg ich Ärger....
Julius ¶
1. März 2009, 01:56 Uhr
C verführt zu lustigen aber teils arg unübersichtlichen Pointertricks, Redundanz in Datenbanken ist auch sehr beliebt bei dem ein oder anderen und bei so mancher Scriptsprache gibt es Typecasting-Wirrwarr. Besonders beliebt für Codemurks ist ja seit jeher PHP. Ganz großer Käse ist natürlich sowas wie http://foo.bar?site=baz.php (ich bau mein eigenes CMS mittels include) und einige greifen sogar aus Verzweiflung bzw. Schluderei/Unwissen zu eval - und das 'funktioniert' oft auch - bis jemand mal ein exec und ein rm -rf einschleust ;)
Julius ¶
1. März 2009, 02:27 Uhr
...andere schöne Beispiele für Codingmurks findet man übrigens immer mal wieder auf thedailywtf.com
Benni ¶
1. März 2009, 07:28 Uhr
Ach du Schande. Wie kann man nur solchen Code schreiben? Gut, dass sowas bei uns in der Firma nicht vorkommt :-)
Daniel ¶
1. März 2009, 09:20 Uhr
Solche Codewunder gibt es ja in jeder Sprache wobei die Beispiele hier echt der Hammer sind. Ich muss an dieser Stelle aber zugeben das mein erstes "CMS" für ne private Seite auch oft auf include zurückgriff. ;-)
dummy ¶
1. März 2009, 12:40 Uhr
Warum denn unbedingt eine Funktion statt include bei einer Formularauswertung?
*mal so doof frag*
Peter ¶
1. März 2009, 12:48 Uhr
Zitat Marc:
Das wäre eine mögliche Erklärung, aber keine Entschuldigung.
Zitat dummy:
Warum nicht? Außerdem hätte man das dann als Plugin einbinden können statt den CMS-Core zu hacken.
dummy ¶
1. März 2009, 13:10 Uhr
Zitat dummy:
Warum nicht? Außerdem hätte man das dann als Plugin einbinden können statt den CMS-Core zu hacken.
hm ok, habe halt bisher auch immer include benutzt und bin sehr zufrieden damit. Wenn ich nochmal irgendwann mein CMS umstrukturieren sollte befass ich mich damit mal noch etwas genauer. Sehe halt grade nicht so den Vorteil an der Funktion... aber einbinden und plugin.. muss ich mir nochmal etwas genauere Gedanken machen...
e7 ¶
1. März 2009, 14:58 Uhr
Der erste Code dürfte als "polymorpher Code" durchgehen... :)
datenkind ¶
1. März 2009, 19:18 Uhr
Also ich persönlich bin kein Hardcore-Coder, aber was einem teilweise so als Typo3-Ext angekullert kommt, lässt selbst mir die Kinnlade runterklappen. War neulich auf der Suche nach einer Wetter-App, da gibts eine, die sich selber 3 Mal komplett selber parst, damit auch alle Marker im (eigentich komplett überflüssigen) Temlate ersetzt werden.
Andere Geschichte: Bin mal bei einem Typo3-Projekt engestiegen, wo mir durch ein langatmiges Vortreffen vermttelt wurde, der Coder sei langjährig erfahren. Ich hatte zu dem Zeitpunkt ca. ein 3/4 Jahr mit T3 zu tun. Aber der Hammer war dann das TypoScript, was aus dem Browser ächzte: wüster Spagetthicode, kreuz und quer, der reinste Kraut- und Rübenacker ... Ich dacht, ich bekomm das kalte Kotzen.
Aktuell hänge ich wieder an sowas: System, das Links zu internen Seiten nur an der im URL angegebenen ID erkennt - da kannste selbst „Kackwurst“ + ID hinschreiben und kommst trotzdem ans Ziel ...
Das komische an all diesem Gehacke ist ja, dass es überall ist, nicht nur beim Wald- und Wiesencoder, sondern auch bei denen, wo du denkst, dass die es drauf haben. Aber die Ernüchterung kommt da ganz schnell. Nur gut, dass die nicht an anderer Leute Autos schrauben, OPs am offenen Herzen durchführen oder einfach nur meinen Rasen mähen ...
Julius ¶
2. März 2009, 14:21 Uhr
nichts gegen include per se (im gegensatz zu dem bösen eval). man sollte es nur nicht so benutzen, daß es das scheunentor ist, wodurch andere quatsch einschleusen können. in z.B. einem autoloader, der irgendwelche klassen einbindet hab ich eher kein problem mit include/require - also: kapseln, bitte incl. geheimnisprinzip, wiederverwendbarkeit bitte ohne c+p ;) und ein paar mehr zeilen schreiben (incl. sprechende variablennamen) allein für die übersichtlichkeit hat auch noch keinen umgebracht (dafür gibts ja höhere, lesbare sprachen und structural programming...).
Rufinus ¶
3. März 2009, 12:27 Uhr
@datenkind: ich mein sorry, aber was willst anderes erwarten in T3. Ich werd nie begreifen warum T3 heutzutage noch eingesetzt wird. Vor ein paar jahren mag es seiner zeit voraussein, aber das ist lange vorbei.
lg
datenkind ¶
3. März 2009, 22:50 Uhr
Das liegt nich primär an T3 – es sind die Coder der Extensions, die im letzten Jahrtausend kleben geblieben sind. Dass es gut und vor allem auch professionell geht, beweisen gewisse Coder weiterhin, die auf strikte Trennung der Funktionen und der Templates achten. Ich würde das nicht so pauschalisieren.
Mein letztes Beispiel bezog sich nicht auf Typo3, sondern das ist ein Closed Source CMS einer näher stehenden Firma … War da etwas voreilig, denn das hab ich via iPhone getippt, daher auch die vielen fehlenden Buchstaben *graus* ;)