PHP Best Practices: Teil 1

In diesem ersten Teil der PHP Best Practices Serie werden bewährte Methoden vorgestellt, wie man mit PHP optimal und sauber programmiert. Viele Codebeispiele verdeutlichen die Best Pracitce Ansätze für PHP.

require statt include

Man sollte immer die require() und require_once() Funktionen statt der include() und include_once() nutzen. Beide importieren zwar externe Skripte, der Unterschied ist aber, dass die require-Funktionen ein weiteres Ausführen des Skripts verhindern, wenn die Ziel-Datei so nicht existiert. Die include-Funktionen lassen dagegen ein weiteres Ausführen zu, was schlecht ist, da eine weitere Programmausführung keinen Sinn macht, wenn wichtige Bibliotheken nicht importiert werden konnten.
Folgende Beispiele zeigen die Funktionsweise beider Funktionen:

<?php

include_once('asdf.php');

echo "das geht noch.";

?>

 
<?php

require_once('asdf.php');


echo "das geht noch.";

?>

Einfache Anführungsstriche für Strings

Wann immer es möglich ist, sollte man für Strings nur einfache Anführungsstriche '' verwenden. Den bei den doppelten ""  parst der Parser den String nach Variablen und besonderen Zeichen, wie z. B. \n oder \t. Das führt zu längeren Ausführungszeiten der Skripte und damit zu längeren Ladezeiten der Webseite.

Also immer einfache Anführungsstriche verwenden, wenn es möglich ist, d. h. wenn im String keine Variable eingebunden ist oder keine dieser Backslash-Zeichen.

Keine Funktionen innerhalb einer Schleifendeklaration

Es wird sehr gerne gemacht, ist aber eigentlich völliger Schwachsinn. Man sollte keine Funktionen innerhalb einer Schleifendeklaration aufrufen.
So also nicht:

for ($i=0; $i<count($array); $i++)
{
    //mach was...
}

Warum?

Hier wird die Funktion count() bei jeder einzelnen Iteration aufgerufen, was eigentlich gar nicht nötig ist, wenn man sich die folgende Alternative ansieht:

$count = count($array);
for($i = 0; $i < $count; $i++)
{
    //mach was...
}

Hier wird die Funktion count() nur einmal aufgerufen, was wesentlich performanter ist.

Code kommentieren und dokumentieren

Jeder sollte seinen Code mit aussagekräftigen Kommentaren versehen. Dies erleichtert die Verständlichkeit von Programmcode. Gerade wenn die „Gefahr“ besteht, dass sich jemand anderes mit dem eigenen Programmcode auseinandersetzen muss, ist eine gute Kommentierung sehr wichtig. Jeder, der selbst schon einmal unkommentierten Code von einem anderen Programmierer gelesen hat, weiß, wovon ich rede.
Doch auch aus rein egoistischen Gründen ist eine ordentliche Kommentierung wichtig. Es gibt nichts entwürdigenderes, als nach einem halben Jahr seinen eigenen Programmcode nicht mehr zu verstehen, weil man die Gedankengänge von damals nicht mehr nachvollziehen kann. Ich rate deshalb zum sauberen kommentieren, um einem erneuten schreiben von bereits existierendem Code zu vermeiden.
Hervorragend geeignet für die Dokumentation von PHP-Projekten ist der phpDocumentor. Man muss sich dabei zwar an die Kommentierungsrichtlinien halten, die er vorgibt, bekommt im Gegenzug dafür eine ausgezeichnete Dokumentation seiner eigenen PHP-Dateien.

Typsicheres Coding durch ===

PHP ist eine Programmiersprache, die keinen großen Wert auf strenge Typisierung legt. D. h. eine Variable kann z. B. mal ein String sein und dann später ein Integer.
Wenn man nun versucht zwei unterschiedliche Datentypen zu vergleichen, kann es zu Problemen kommen:

 
1 == '1.'

Der Vergleich ergibt true.
Das Dilemma beginnt, weil PHP die ‚1‘ als Integer umwandelt.
Nun sorgt PHP dafür, dass der Vergleich durchgeführt werden kann, indem beide Werte auf einen einheitlichen Datentyp gebracht werden, nämlich Integer. Dadurch wird der ‚.‘ von ‚1.‘ abgeschnitten, weil Integers nur aus Ziffern bestehen können. Somit ergibt der Vergleich true.
Vermeiden kann man diese Schwächen von PHP durch das Nutzen von der drei-Zeichen-Vergleichs-Variante mit === und !===. Also so:

 
'1.' === 1

Hier ergibt der Vergleich tatsächlich false, so wie es sein soll.

Nur lange öffnende PHP-Tags

Es gibt verschiedene öffnende Tags, mit denen man ein PHP-Skript beginnen kann, damit der Parser weiß, dass er jetzt arbeiten muss:

• <?
• <?
•  <%
• <?php

Alle Varianten außer <?php sind veraltet und sollten nicht mehr genutzt werden. Obendrein kann es zu unschönen Fehlern kommen, wenn man z. B. <? nutzt, weil dies heute für XML-Deklarationen gedacht ist.

Returns am Anfang

Um die Lesbarkeit von Funktionen und Methoden zu erhöhen, sollte man Bei Abfragen das return-Statement immer in der ersten Abfrage machen. Folgendes Beispiel verdeutlicht das:

<?php

function foo($var_1, $var_2)
{
    if ($var_1 === var_2)
    {
        //Hier
        //steht
        //z. B.
        //der
        //Code
        //für
        //diese
        //Bedingung
        return $var_return;
    }
    else 
    {
        return false;
    }
}
?>

Das hier ist relativ schlecht zu lesen, weil das return false erst nach der kompletten ersten if-Abfrage kommt.
Besser wäre es, erst zu Prüfen, ob die Bedingung  $var_1 === var_2 nicht erfüllt ist, dann false zurück zu geben und andernfalls die andere if-Abfrage auszuführen:

<?php

function foo($var_1, $var_2)
{
    if ($var_1 !== var_2)
    {
        return false;
    }
    else 
    {
        //Hier
        //steht
        //z. B.
        //der
        //Code
        //für
        //diese
        //Bedingung
        return $var_return;
    }
}
?>

Demnächst folgt der Teil 2 dieser Serie mit weiteren interessanten Best Pracitce Lösungen für PHP!

Kommentare

Axel Scheuering

0

 

 

Sorry liebe Leser,
ich sehe in den Statistiken, dass sehr viele Menschen diesen Artikel lesen. Angekündigt habe ich ja einen weiteren Teil. Bin aber bis jetzt nicht dazu gekommen. Aber steht auf meiner Liste!

Mittwoch 28 Oktober 2009, 22:58

Antwort schreiben

Name *
Code   
ChronoComments by Joomla Professional Solutions

Kommentar abgeben

Cancel

Name *
Code   
ChronoComments by Joomla Professional Solutions

Kommentar abgeben