Namenskonventionen

Klassen

Zend Framework standardisiert eine Klassennamenkonvention, wobei die Namen der Klassen direkt mit den Verzeichnissen übereinstimmen müssen, in welchen sie gespeichert sind. Das Basisverzeichnis der Zend Framework Standard Bibliothek ist das "Zend/" Verzeichnis, wobei das Basisverzeichnis der Zend Framework Extras Bibliothek im "ZendX/" Verzeichnis ist. Alle Zend Framework Klassen werden hierarchisch unter dem gleichen Basisverzeichnis gespeichert.

Klassennamen dürfen nur alphanumerische Zeichen enthalten. Ziffern sind in Klassennamen gestattet, es wird aber in den meisten Fällen davon abgeraten. Unterstriche sind nur statt des Pfadtrenners gestattet -- der Dateiname "Zend/Db/Table.php" muss übereinstimmen mit dem Klassennamen "Zend_Db_Table".

Wenn ein Klassenname aus mehr als einem Wort besteht, muss der erste Buchstabe von jedem neuen Wort großgeschrieben werden. Durchgehende Großbuchstaben sind nicht erlaubt, z.B. eine Klasse "Zend_PDF" ist nicht erlaubt, aber "Zend_Pdf" ist akzeptabel.

Diese Konventionen definieren einen Pseudo-Namespace Mechanismus für Zend Framework. Zend Framework wird das PHP Namespace Feature einbauen, sobald es verfügbar ist und es für unsere Entwickler in deren Anwendungen ohne Bedenken verwendbar ist.

Als Beispiel dieser Klassennamenkonvention sei auf die Klassennamen in der Standard und der Extra Bibliothek verwiesen.

Note: Wichtig: Klassenname in Code, welcher mit dem Framework ausgeliefert werden muss, aber nicht Teil der Standard oder Extras Bibliothek ist (z.B. Anwendungscode oder Bibliotheken, die nicht von Zend ausgeliefert werden), dürfen nie mit "Zend_" oder "ZendX_" beginnen.

Abstrakte Klassen

Generell folgen abstrakte Klassen der gleichen Konvention wie Klassen, mit einer zusätzlichen Regel: Die Namen von abstrakten Klassen müssen mit dem Term "Abstract" enden, und dem Term darf kein Unterstrich vorangestellt sein. Als Beispiel wird Zend_Controller_Plugin_Abstract als ungültig betrachtet, aber Zend_Controller_PluginAbstract oder Zend_Controller_Plugin_PluginAbstract wären gültige Namen.

Note: Diese Namenskonvention ist neu seit Version 1.9.0 des Zend Frameworks. Bei Klassen vor dieser Version kann es sein, dass sie dieser Regel nicht folgen, aber sie werden in Zukunft umbenannt, um ihr zu entsprechen.
Der Hintergrund dieser Änderung ist die Verwendung von Namespaces. Da wir auf Zend Framework 2.0 und die Verwendung von PHP 5.3 zugehen, werden wir Namespaces verwenden. Der einfachste Weg, die Konvertierung zu Namespaces zu automatisieren, besteht darin, die Unterstriche in Namespace Separatoren zu konvertieren -- aber in der alten Namenskonvention, lässt dies den Klassennamen einfach als "Abstract" oder "Interface" zurück" -- beide sind reservierte Schlüsselwörter in PHP. Wenn wir den Namen der (Unter)Komponente dem Klassennamen voranstellen, können wir diese Probleme vermeiden.
Um die Situation zu illustrieren, nehmen wir an, dass die Klasse Zend_Controller_Request_Abstract konvertiert wird, um Namespaces zu verwenden:

  1. namespace Zend\Controller\Request;
  2.  
  3. abstract class Abstract
  4. {
  5.     // ...
  6. }
Natürlich wird das nicht funktionieren. In der neuen Namenskonvention würde dies aber trotzdem zu folgendem werden:
  1. namespace Zend\Controller\Request;
  2.  
  3. abstract class RequestAbstract
  4. {
  5.     // ...
  6. }
Wir bleiben trotzdem bei der Semantik und der Trennung auf Namespaces, während wir die Probleme mit den Schlüsselworten vermeiden; gleichzeitig beschreibt dies abstrakte Klassen besser.

Interfaces

Generell folgen Interfaces der gleichen Konvention wie Klassen, mit einer zusätzlichen Regel: Die Namen von Interfaces können optional mit dem Term "Interface" enden, aber dem Term darf kein Unterstrich vorangestellt sein. Als Beispiel wird Zend_Controller_Plugin_Interface als ungültig betrachtet, aber Zend_Controller_PluginInterface oder Zend_Controller_Plugin_PluginInterface wären gültige Namen.

Während diese Regel nicht benötigt wird, wird sie sehr empfohlen, da sie Entwicklern einen guten visuellen Hinweis gibt, welche Dateien ein Interface enthalten und welche Klassen.

Note: Diese Namenskonvention ist neu seit Version 1.9.0 des Zend Frameworks. Bei Klassen vor dieser Version kann es sein, dass sie dieser Regel nicht folgen, aber sie werden in Zukunft umbenannt um ihr zu entsprechen. Siehe den vorhergehenden Abschnitt für weitere Informationen über die Hintergründe für diese Änderung.

Dateinamen

Für alle anderen Dateien sind nur alphanumerische Zeichen, Unterstriche und der Bindestrich ("-") gestattet. Leerzeichen sind völlig verboten.

Jede Datei, die irgendeinen PHP-Code enthält, sollte mit der Endung ".php" enden, mit Ausnahme der View-Skripte. Die folgenden Beispiele zeigen akzeptierbare Dateinamen für Zend Framework Klassen:

  1. Zend/Db.php
  2.  
  3. Zend/Controller/Front.php
  4.  
  5. Zend/View/Helper/FormRadio.php

Dateinamen müssen den Klassennamen wie oben beschrieben entsprechen.

Funktionen und Methoden

Funktionsnamen dürfen nur alphanumerische Zeichen enthalten. Unterstriche sind nicht gestattet. Ziffern sind in Funktionsnamen gestattet, aber in den meisten Fällen nicht empfohlen.

Funktionsnamen müssen immer mit einem Kleinbuchstaben anfangen. Wenn Funktionsnamen aus mehr als einem Wort bestehen, muss der erste Buchstabe jedes Worts großgeschrieben werden. Das wird häufig "camelCase"-Formatierung genannt.

Ausführlichkeit wird generell befürwortet. Funktionsnamen sollten so ausführlich wie möglich sein, um deren Zweck und Verhalten zu erklären.

Das sind Beispiele akzeptierbarer Namen für Funktionen:

  1. filterInput()
  2.  
  3. getElementById()
  4.  
  5. widgetFactory()

Für objektorientiertes Programmieren sollten Zugriffspunkte für Instanzen oder statische Variablen immer mit "get" oder "set" beginnen. Wenn Design-Pattern implementiert werden wie Singleton oder das Factory Pattern, sollte der Name der Methode den Namen des Pattern enthalten, wo es praktikabel ist, um das Verhalten besser zu beschreiben.

Für Methoden in Objekten, die mit dem Modifikator "private" oder "protected" deklariert sind, muss das erste Zeichen des Namens der Methode ein einzelner Unterstrich sein. Das ist die einzige akzeptable Anwendung von einem Unterstrich im Namen einer Methode. Methoden, die als "public" deklariert sind, sollten nie einen Unterstrich enthalten.

Funktionen im globalen Bereich (auch "floating functions" genannt) sind gestattet, aber es wird in den meisten Fällen davon abgeraten. Diese Funktionen sollten in einer statischen Klasse gewrappt werden.

Variablen

Variablennamen dürfen nur alphanumerische Zeichen enthalten. Unterstriche sind nicht gestattet. Ziffern sind in Variablen gestattet in den meisten Fällen aber nicht empfohlen.

Für Instanzvariablen, die mit dem Modifikator "private" oder "protected" deklariert werden, muss das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein. Das ist die einzige akzeptierte Anwendung eines Unterstriches in einem Variablennamen. Klassenvariablen, welche als "public" deklariert werden, sollten nie mit einem Unterstrich beginnen.

Wie bei Funktionsnamen (siehe Abschnitt 3.3) müssen Variablennamen immer mit einem Kleinbuchstaben starten und der "camelCaps"-Schreibweise folgen.

Ausführlichkeit wird generell befürwortet. Variablen sollen immer so ausführlich wie möglich sein, um die Daten zu beschreiben, die der Entwickler in ihnen zu speichern gedenkt. Von knappen Variablennamen wie "$i" und "$n" wird abgeraten für alles außer für kleinste Schleifen. Wenn eine Schleife mehr als 20 Codezeilen enthält sollten die Index-Variablen einen ausführlicheren Namen haben.

Konstanten

Konstanten können beides enthalten, sowohl alphanumerische Zeichen als auch Unterstriche. Ziffern sind in Konstantennamen gestattet.

Alle Buchstaben, die in Konstantenname verwendet werden, müssen großgeschrieben werden, während Wörter in einem Konstantennamen durch Unterstriche getrennt werden müssen.

Zum Beispiel ist EMBED_SUPPRESS_EMBED_EXCEPTION gestattet, aber EMBED_SUPPRESSEMBEDEXCEPTION nicht.

Konstanten müssen als Klassenkonstanten mit dem Modifikator "const" definiert werden. Die Definition von Konstanten im globalen Bereich mit der "define" Funktion ist gestattet, aber es wird es wird stärkstens davon abgeraten.

blog comments powered by Disqus