Strasser Simon.de

if ($user->isAdmin) doSomeAdminThings();

Dieser Code ist syntaktisch korrekt und arbeitet auch so, wie es erwartet wird. Wenn Adminrechte verfügbar sind, dann wird die Funktion doSomeAdminThings() ausgeführt. Wenn wir nun jedoch nach einiger Zeit eine weitere Funktion einfügen, so kann dies zu unersichtlichen Fehlfunktionen führen.

if ($user->isAdmin) doSomeAdminThings(); doSomeAdminWork();

Beim Überfliegen des Quellcodes wird dieser Fehler nur von den wenigsten bemerkt. Jeder erwartet, dass sowohl doSomeAdminThings() als auch doSomeAdminWork() lediglich ausgeführt werden, wenn der Benutzer Administrator ist. Doch kann man nun feststellen, dass die Funktion doSomeAdminWork() immer ausgeführt wird, egal ob der User Admin ist oder nicht. Grund hierfür ist, dass lediglich ein Befehl von der If-Bedingung ohne Klammern umschlossen wird.

if ($user->isAdmin) 
{
       doSomeAdminThings(); 
       doSomeAdminWork();
}

Forderung: Um Probleme im Programmfluss durch fehlerhafte Programmierung zu vermeiden sollten alle Kontrollstrukturen immer mit Klammern versehen werden.

// Addition von a und b
$c = $a + $b;
// Ausgabe der Summe von $a und $b, repräsentiert durch die Variable $c
echo $c;

Ich denke jedem wird bereits beim ersten Betrachten klar, dass hier eindeutig übertrieben wurde, da hier eindeutig ohne Probleme erkannt werden kann was passiert.

...
for ($i=count($itemsOfVar) - count($itemsOfOthers); $i<count(base::getObj('objects')->userCounter); $i = $i * 2)
...

Eine solche Quellcode-Zeile, welche den Programmierer auf den ersten Blick mit Informationen erschlägt, sollte unbedingt kommentiert werden. Wenn jemand Fremdes diesen Code sieht, so wird er nur mit einem größeren Zeitaufwand erschließen können, was genau geschieht.

Forderung: Beim Kommentieren sollte der gesunde Menschenverstand genutzt werden. Es sollte nicht übertrieben werden, jedoch kann man grundsätzlich sagen, dass eine Kommentarzeile zu viel nicht so sclimm ist, wie eine Kommentarzeile zu wendig!

public function addDatabase(abstractDatabaseObject $dbObj) { ... }

Nun können an die Funktion addDatabase nur noch Objekte von Klassen übergeben werden, die von abstractDatabaseObject erben, es ist also sichergestellt, dass es sich um ein DatabaseObject handelt. Natürlich könnte man nun auch innerhalb der Funktion mit if-Abfragen usw. überprüfen ob es sich wirklich um ein solches handelt, der Aufwand wäre jedoch im Vergleich gigantisch. Auch sind Type-Hints sehr nützlich wenn man eine IDE wie etwa NetBeans einsetzt, da nun die Quellcode-Vervollständigung erkennt, von welchem Type eine Variable ist.

Forderung: Type-Hints müssen bei allen Funktionen verpflichtend eingesetzt werden!

Forderung: PHP-Skripte werden immer mit <?php begonnen. Bei Dateien die lediglich Klassen enthalten wird kein abschließender PHP-Tag verwendet.

Forderung: Temporäre Variablen werden durchgehend klein geschrieben, mehrere Wörter werden mit Unterstrichen getrennt. Klassenvariablen werden beginnen mit einem Kleinbuchstaben wenn sie Private oder Protected sind, ansonsten mit einem Großbuchstaben, mehrere Wörter werden durch Großbuchstaben getrennt. Konstante werden durchgehend groß geschrieben.

Das folgende Beispiel soll den Nutzen dieser Methode verdeutlichen:

class flugzeug
{
        protected $flugzeugName;
        protected $pilotName;
 
        public function getFlugzeugName()
        {
              return $this->flugzeugName;
        }
 
        public function getPilotName()
        {
              return $this->pilotName;
        }
 
        public function setPilotName($name)
        {
              $this->pilotName = $name;
        }
}

Während der Pilot eines Flugzeuges theoretisch jederzeit wechseln kann (=> Getter und Setter), wird der Name eines Flugzeuges nicht geändert (=> Getter, jedoch kein Setter). Würde man den Flugzeugnamen nun etwa im Konstruktor übergeben so könnte er für die gleiche Instanz der Klasse nicht mehr geändert werden, da keine Setter-Methode existiert.

Forderung: Nutzung von Getter-/Setter-Methoden für den Zugriff auf öffentliche Variablen einer Klasse sowie zur Datenkapselung.

Forderung: Wahrheitswerte dürfen, soweit nicht der komplette Funktionsablauf ein anderer ist, als Parameter übergeben werden.

Forderung: Für jede Klasse muss eine eigene Datei erstellt werden, welche den gleichen Namen wie die Klasse tragen sollte.

include("aaa.php");
include("aab.php");
...
include("zzz.php");

Nun argumentieren manche Programmierer, dass sie ja jede der eingebundenen Klassen unter bestimmten Umständen benötigen und sie deshalb einbinden müssen. Auch könne man die Klassen nicht erst bei der Benutzung per include einbinden, da es ja so vorkommen könnte, dass eine Datei mehrmals eingebunden wird. Dieses Problem lässt sich jedoch sehr leicht über eine Autoloader-Funktion lösen, wenn man für alle Klassen allgemeingültige Regeln bei ihrer Bennenung und Speicherung einhält. Sollte dies aufgrund zu komplexer Strukturen nicht möglich sein, so könnte man etwa auch mit einer Loader-Klasse arbeiten:

abstract class ClassHelper
{
      private static $alreadyIncluded = array();
 
      public static function includeClass($file)
      {
             if (!array_key_exists($file, self::$alreadyIncluded))
             {
                    include($file);
                    self::$alreadyIncluded[] = $file;
             }
      }
}

Forderung: Klassen sollen erst eingebunden werden, wenn sie vom Skript benötigt werden.

if (($user->isAdmin || $user->isMod) && (!$system->isEnabled && !$user->isLocked)) { }

Wesentlich übersichtlicher wäre es doch nun etwa so:

if ( ($user->isAdmin || $user->isMod)
    &&
    (!$system->isEnabled && !$user->isLocked)) {}

Auch bei Arrays und Funktionen mit vielen Parametern sollte man mehrere Zeilen verwenden um die Übersichtlichkeit zu wahren. (Hinweis: Auch Strings können über mehrere Zeilen gehen!

Forderung: Die Grenze von 80 Zeichen pro Zeile sollte nur in Ausnahmefällen überschritten werden!