Defensives Programmieren mit PHP

Heute geht es um die Technik des defensiven Programmierens. Ihr kennt es ja bestimmt vom Autofahren. Immer defensiv. Lernt man ja schon in der Fahrschule. Aber was bedeutet das? Ich würde es mal mit “immer mit den Fehlern der anderen rechnen” übersetzen.

Übertragen auf die Softwareentwicklung heißt es genau das Gleiche. Geht einfach davon aus, dass die Verwender eurer Funktionen ein wenig auf den Kopf gefallen sind und gerne mal was falsch machen. Bereitet euch also drauf vor. Vielleicht nicht gleich auf den DAU, aber in die Richtung kann es gehen.

function fahrenheitToCelcius( $fahrenheit )
{
  return ( $fahrenheit - 32 ) * 5 / 9;
}

An dem Beispiel sehen wir schon, dass schwache Typisierung das Defensive schon ein wenig erschwert. Was passiert in unserem Fall, wenn der Anwender einen String übergibt? Sollte das ganze Programm dann einfach abstürzen? Nö, eigentlich nicht. Eine Exception wäre schon ganz nett.

[sc:adsense]

function fahrenheitToCelcius( $fahrenheit )
{
  if ( !is_number( $fahrenheit ) {
    throw new InvalidArgumentException( '$fahrenheit must be a number.' );
  }
  return ( $fahrenheit - 32 ) * 5 / 9;
}

So, schon kann man nichts mehr verbocken, wenn die Funktion durchgelaufen ist, dann funktioniert sie auch. Zumindest syntaktisch. Prüfen müsste ich jetzt noch, ob $fahrenheit größer ist als -459,67 (absoluter Nullpunkt).

function fahrenheitToCelcius( $fahrenheit )
{
  if ( !is_numeric( $fahrenheit ) {
    throw new InvalidArgumentException( '$fahrenheit must be a number.' );
  }
  if ( $fahrenheit < -459.67 ) {
    throw new InvalidArgumentException( '$fahrenheit must be greater than -459.67.' );
  }
  return ( $fahrenheit - 32 ) * 5 / 9;
}

So,  ich glaube jetzt haben wir wirklich alle Gegebenheiten analysiert. Damit sollte die Funktion jetzt wirklich DAU sicher sein. Ihr merkt natürlich, dass wir auf einmal das siebenfache an Zeilen Code haben. Kann also relativ aufwendig sein.

[sc:adsense]

Wichtig hierbei ist es das Gleichgewicht zwischen Nutzen und Kosten zu bestimmen. Nutzen ist in diesem Fall die Stabilität der Methode. Kosten ist der Mehraufwand für die sechs extra Zeilen Code.  Aber wem sag ich das. Irgendwann bekommt man ein Gespür dafür, wie DAU-sicher man arbeiten muss.

Wer sich noch ein wenig in das Thema einarbeiten will, der sollte sich mal assert anschauen. Das wäre hier das Mittel der Wahl, aber ich wollte es mir für einen anderen Artikel aufheben.