Facebook
Twitter
Google+
Kommentare
6
Willkommen bei "the web hates me". Mittlerweile hat unser Team ein tolles neues Monitoringtool für Agenturen gelauncht. Unter dem Namen koality.io haben wir einen Service geschaffen, der er Agenturen ermöglicht mit sehr geringen Kosten alle Ihre Webseiten zu überwachen.

Dinge, die PHP schwer zu analysieren machen

Wie die meisten von euch ja wissen, bin ich ein großer Freund von statischer Code-Analyse. Also Untersuchungen, die man auf den Quellcode ausführen kann, ohne das Programm laufen lassen zu müssen. Diese Technik ist in den meisten Programmiersprachen an der Tagesordnung und dort kann man sicher auch viel lernen. Leider gibt es in PHP es ein paar Dinge, die einen das Leben schwer machen, wenn man eine Code-Analyse-Fetisch hat.

Als Qualitätsmanager muss man aber das Fetisch-Gen haben und deswegen beschäftigt man sich auch rund um die Uhr mit dem Thema. Das größte Problem ist die fehlende bzw. schwache Typisierung. Ohne zu wissen, was für eine Klasse ich da im Code habe, kann ich auch nicht analysieren. Da könnte ja jeder kommen! Will ich also eine bestmögliche Analyse starten, so sollte ich ein paar Dinge beachten und ein paar besser nicht tun. Wobei man viel tun kann, wenn man es richtig macht. Die Leute die PHP entwerfen haben sich ja schließlich auch was dabei gedacht, aber wie immer im Leben kann das richtige Werkzeug in den falschen Händen Probleme bereiten.

  • mixed als Rückgabetyp – Der Rückgabetyp in PHP ist nicht typisiert und wird es wohl auch nicht so schnell (auch wenn ich da mal was in PHP 6.0 gelesen habe). Wenn ich aber keine Ahnung habe, was da zurückkommt, wie soll ich denn dann damit arbeiten? Oft entscheidet sich so etwas ja auch erst zur Laufzeit und dann habe ich bei statischer Analyse echt miese Karten.
  • Magische Methoden – Große Probleme können auch ein paar der magischen Methoden bereiten. __call ist mein Favorit dabei. Existiert die Methode die ich Aufrufe? Um die Frage zu beantworten, muss ich mich meistens in den Code reindenken und das in einen Algorithmus zu packen halte ich für sehr schwer.
  • call_user_func – Hier habe ich noch weniger Ahnung, was passiert. Hier müsste man dafür sorgen, dass egal was ich aufrufe, der Rückgabetyp immer identisch ist. Wie gesagt, in den richtigen Händen ist vieles OK. Problemtisch wird es dann, wenn ich zum Beispiel versuchen will rauszufinden, ob ich toten Code im Projekt habe. Ob eine Methode benutze wird im gesamten Projekt wird unmöglich.
  • Variable Variablen – Ich glaube dazu brauche ich nichts sagen. Daraus kann ich die Kombination aus magischen Methoden und call_user_func bauen, ohne das ich überhaupt noch was über den Code aussagen kann.

Ich könnte euch noch 100te solcher Punkte aufzählen, wenn mir welche einfallen würden. Egal ihr habt bestimmt noch Beispiele und ich weiß schon wieder, was ich in den nächsten Tagen schreiben kann. Der richtige Umgang mit „fiesen“ PHP Methoden.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

6 Comments

  1. Geht doch viel einfacher:

    return $this->{$foo}->{$bar}($args);

    Abgesehen davon kann man in PHP sowieso Klassenvariablen zuweisen die gar nicht definiert sind, ohne eine Fehlermeldung zu ernten.

    Solche Schreibfehler würde PHP nicht melden:

    $this->conenction = Db::connect($foo);

    Das wiederum kann man aber einfach vermeiden:

    public function __get($name)
    {
    throw new Exception(„Attempt to access undefined var ‚$name‘.“);
    }

    Reply
  2. Die Evolution hätte nicht PHP geküsst, wenn es anders wäre als es ist. Na ja und Nils hätte nicht diesen Blog Titel gefunden.

    Es gibt sie – die Sprachen für die Kontrollfanatiker. Die Gründe für statische Analyse sind „statisch“ betrachtet nachvollziehbar, aber im dynamischen Umfeld der sekundlichen Codeänderung externer Libraries und immer kürzerer Lebenszyklen von Softwareprodukten bezweifle ich den Nutzen.

    Unit Tests, Security Tests und Performance Test sind die letzten Freunde der Qualitätssicherung. Denn Rest betrachte als BlackBox und vertraue den Entwicklern. Die arbeiten schon am nächsten Hammer Produkt.

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen