Dinge, die PHP schwer zu analysieren machen

Lesetipps

1. Warum call_user_func() vielleicht doch nicht so böse ist?!
2. Projektwerkstatt: Rückgängig machen
3. Zwei Dinge, die mir bei PHPUnit fehlen

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.

6 Kommentare »

• 
  

  Nils Langner

  am 11. Februar 2010 um 07:16 Uhr

  include $file ist mir gerade noch eingefallen. Ist zwar unschön, findet man aber sehr häufig in Applikationen. Aber auch hier gilt, dass man es schön einsetzen kann.

• 
  

  nick3331

  am 11. Februar 2010 um 09:19 Uhr

  Wie wärs mit eval?

• 
  

  Nils Langner

  am 11. Februar 2010 um 09:26 Uhr

  Peinlich! Da habe ich ja den Godfather of fiesen Code vergessen. Danke nick3331!

• 
  

  Tom

  am 11. Februar 2010 um 09:39 Uhr

  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’.”);
  }

• 
  

  Simon

  am 11. Februar 2010 um 22:16 Uhr

  Die schwache Typisierung ist aber auch oft von Vorteil und wenn ich da an C++ denke, bin ich doch ganz froh, PHPler zu sein.

• 
  

  jens

  am 15. Februar 2010 um 11:42 Uhr

  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.

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar