Kategorien
MeinPHP: Wer baut das fieseste Skript?
Am letzten Freitag ging was schief mit unseren Blogartikel. Wir hatten ausversehen zwei an einem Tag veröffentlicht und eigentlich machen wir das ja nicht. Aus diesem Grund habe ich diesen Artikel hier auch wieder rausgenommen und auf heute verschoben. Wundert euch also nicht, wenn er euch bekannt vorkommt.
Wir hatten im Dezember ja schon mal eine Folge MeinPHP auf die Leser losgelassen. Bei MeinPHP geht es eigentlich darum eine Aufgabe, die wir stellen möglichst elegant zu lösen und in seinem Forum, Blog oder woanders zu Posten. Ich habe lange überlegt, was man als nächste Herausforderung machen könnte. Und heute kam mir endlich die Idee.
PHP ist meine bevorzugte Sprache, wir ihr ja vielleicht wisst, nichtsdestotrotz kann man echt fiese Sachen damit bauen und das schlimmste daran ist, man findet diese fiesen Sachen immer wieder in produktiv eingesetzten Tools. Und warum? Weil man es kann! (Danke Olaf für die Aussage). Aus diesem Grund möchte ich heute einen kleinen Contest ausschreiben. Wer kann das fieseste Skript basteln?
Meine Theorie ist ja, dass in einem wirklich schrecklichen Programm mindesten ein goto, ein catchable fatal error, ein class_alias, ein $$ und vielleicht ein wenig Reflection dabei sein muss. PHP 5.3 hat echt ein paar schöne „Monster“ mitgebracht, die in den falschen Händen schon ganz schön Schaden anrichten können. Ich selbst werde mich auch daran probieren, habe da auch schon ein paar Ideen.
Anders als beim letzen Mal werden wir keine konkrete Aufgabe aussuchen, seid also kreativ und versucht euch selbst zu schocken. Ich denke mal, dass so zwei Wochen reichen sollten, um was wirklich gemeines zu zaubern. Solange habt ihr also Zeit euch was auszudenken. Wem was eingefallen ist, der kann es mir gerne per E-Mail schicken oder am besten einfach bei sich im Blog zu posten. Nach dem Ablauf der Frist werden wir dann das beste schrecklichste Skript kühren und den Titel „PHP Teufel“ verleihen.
Oft hilft es übrigens auch sich den eigenen alten Code anzuschauen. Zumindest bei mir. Viel Spaß also mit der Aufgabe, ich werde ihn haben.
Wenn ich mein alten Code anschaue bekomme ich entweder eine Gänsehaut oder einen Brechreiz.
Des öfteren schmeis ich mich auch in die Ecke und krümme mich vor Schmerzen, die Lachmuskeln tun nach ner Stunde immer so weh.
Und so ab und an fange ich an wild rumzuzucken.
Ihr seht es ist nicht ganz ungefährlich. Drum , bevor Ihr euren alten Code anschaut, 5 wichtige und weniger wichtige Regeln:
1) Immer in Begleitung eines Erwachsenen, den Code niemals alleine anschauen
2) Stellt sich der Zappelfillip ein ist das ein Anzeichen für eine Überhitzung der Synapsen beim Versuch den Code zu verstehen. Abhilfe: Kopf in die Kloschüssel und kräftig spülen
3) Fängt der Code an nach einer zweiten Chance zu betteln: Sofort delete taste drücken
4) Beim einschleichen des Gedankens, der Code sei doch gar nicht sooo schlecht, ein kleines Refactoring und der is wieder frisch…. Renn so schnell du kannst
5) Bist du in der Arbeit überlege dir schon mal ein paar Ausreden für den Fall das der Chef vorbeikommt und dich an die letzte Gehaltserhöhung erinnert
Und nun steht dem Titel „PHP Teufel“ nichts mehr im Weg.
Ich glaub, das schlimmste was ich bisher gesehen habe war xml gepaart mit eval(). Mann sollte ja im xml php verwenden können. *schauder*
@maren Bei dem yml Parser von Symfony geht das ja ohne Probleme out-of-the-box … Finde yml aber eh schrecklich.
@Bonzei: Danke für die Anleitung. Gleich heute bei der Arbeit mal befolgen.
Geht fieser als eval( $_POST[‚evil‘] ); ? 🙂
Klassiker wäre noch mysql_query( $_GET[’sql‘] );
@Dominik: Oja ich glaube da geht es noch viel fieser 🙂 Obwohl eval() schon auch auf der Liste der gefährlichen Ausdrücke steht. Das Zweite kann man ja in fast jeder Sprache verbocken, oder?
ich hätte da noch include($_GET[‚file‘]); – natürlich nur als Idee und Gott sei dank noch nicht gelesen.
Ich finde das Bsp. von Manuel Pichler auch wunderbar: http://manuel-pichler.de/archives/60-Why-I-love-PHP.html
Hier mal eins (nicht getestet, sollte aber leider funktionieren)
http://dev.trancefish.de/test.html
Nils, meinst du fies im sinne von mach alles falsch was geht und es funktioniert trotzdem ?
Oder fies im sinne von „You are not expected to understand the following code“.
Was letzteres angeht hat manual mit seiner variablen variablen variablen variable sicher den vogel abgeschossen 🙂
Ludwig
@Ludwig: Also den gefährlichsten Code wollte ich eigentlich nicht. Hatte mir schon so etwas wie aus der Feder von Manuel gewünscht.
das ist doch gar nicht mal schlecht oder?
http://nopaste.php-quake.net/250155
hab das mal bei irgendeinem blog mit dem selben thema gelesen und gespeichert 🙂
define(TRUE, false) ist auch lustig, weiß aber nicht ob das in php geht.
Wer ein bisschen Zeit hat, kann sich mal diesen Link durchlesen: http://mindprod.com/jgloss/unmain.html. Zwar nicht unbedingt PHP, aber trotzdem sehr, sehr witzig. 🙂
Was ist an Reflection schlimm?
@Cem Derin: Reflections an sich sind cool, vor allem im Bereich Unit-Testing sehr gut zu gebrauchen! Aber man kann auch ne ganze Klassenstruktur über den haufen werfen:
class C {
private $__privateVar = 'v';
private function __privateMethod() { return 'm'; }
}
$c = new C();
// echo $c->__privateVar; oder
// echo $c->__privateMethod();
// geht natürlich aus guten gründen nicht
$p = new ReflectionProperty('C', '__privateVar');
$p->setAccessible();
echo $c->__privateVar;
Das ganze ist ja nicht sooo schlim auf den ersten Blick. Wenn du aber bedenkst, dass man so in seinen alten Klassen (die vielleicht etwas „schlechter“ gecodet sind) rumpfuschen und rummurksen kann, wird das ganze ziemlich hässlich =)
Ups sorry, das ganze „__privateMethod“ Zeugs kommt raus, schlechtes refactoring von Beispielcode 😉
@Cem: Ich wüsste kein Anwendungsfall, in dem Reflektion Sinn macht, außer man will Annotations implementieren oder CodeAnalyse betreiben. Aber vll. hast du ja ein Bsp.
Das man mit Reflection auch Mist bauen kann rührt in erster Linie daher, dass man mit jedem Sprachkonstrukt Mist bauen kann 😉
Es gibt nicht erst seit gestern den Ansatz reflexiver Programmierung was ich insbesondere in Bezug auf Metaprogrammierung (im Sinne von sich selbst erstellender Programme) höchst interessant finde.
Aber selbst wenn es nur für Unit-Testing verwendet wird und auch nur diesen Zweck hätte, warum wird es in Zusammenhang mit „schlechtem Code“ erwähnt? Das war meine ursprüngliche Frage …
Nur ein kleines Fragment aus Code, den hier jemand 1:1 aus COBOL portiert hat:
try {
# diverse Datenbankzugriffe via Propel-basierter Klassen
# ca. 30 Zeilen
} catch (MyOwnException $exception) {}
Das sieht mir nach einem klaren Exceptions-als-GOTO-Ersatz aus …
class A {}
class B extends A {
public function __construct() {
$args = func_get_args();
call_user_func_array(array($this, „parent::__construct“), $args);
}
}
class C extends B {}
$instance = new C();