im englischen Original von PHP-FIG PSR-1
Dieser Abschnitt der Standards umfasst Codierungselemente, die erforderlich sind um einen hohen Grad der Kompatibilität zwischen PHP-Codes aus verschiedensten Quellen zu erreichen.
<?php
und <?=
Tags verwenden.PHP-Code MUSS ausschließlich UTF-8 ohne BOM verwenden.
Eine Datei SOLLTE entweder neue Symbole (Klassen, Funktionen, Konstanten, etc.) deklarieren und keinerlei 'side effects' enthalten, oder aber sie SOLLTE ausführbare Logik mit 'side effects' enthalten, aber sie SOLLTE NICHT beides tun.
Die Phrase 'side effects' bedeutet 'ausführbare Logik', die nicht in Klassen oder Funktionen gekapselt ist und in der Regel beim 'Includen' der Datei sofort unkontrolliert ausgeführt wird.
'side effects' bezeichnen unter anderem: erzeugen von Ausgaben, benutzen von include() oder require(), verbinden zu externen Services, verändern von INI-Settings, auslösen von Fehlern und Ausnahmen, verändern von globalen oder statischen Variablen, lesen oder schreiben in Dateien oder Datenbanken, und vieles mehr.
Anpassung für WB: Dateien mit 'side effects' MÜSSEN speziell abgesichert werden, damit sie nicht durch z.B. DeepLinks aufgerufen werden und Schaden anrichten können.
Das Nachfolgende ist ein Beispiel einer Datei, die sowohl Deklarationen als auch 'side effects' enthält. Ein Beispiel, das zeigt, was man NICHT machen SOLLTE:
// side effect: ändert Ini-Settings ini_set('errot_reporting', E_ALL); // side effect: lädt eine Datei include('file.php'); // side effect: erzeugt eine Ausgabe echo '<html>'.PHP_EOL; // Deklaration: function foo() { // Funktionskörper }
Das zweite Beispiel ist eine Datei, die nur Deklarationen ohne alle 'side effects' enthält. Ein Beispiel, das immer zu bevorzugen ist.
// Deklaration function foo() { // Funktionskörper } // bedingte Deklaration ist *kein* side effect! if (! function_exists('bar')) { function bar() { // Funktionskörper } }
Die Benennung von Namespaces und Klassen MUSS nach PSR-0 erfolgen.
Das bedeutet, dass jede Klasse in einer eigenen Datei ist und einem Namespace zugewiesen, der wenigstens den Vendor Name als Top-Level hat.
Klassennamen MÜSSEN in StudlyCaps deklariert werden.
Anpassung für WB: Interfaces und abstrakte Klassen müssen im Namen zusätzlich mit dem Suffix Interface oder Abstract ergänzt werden.
Code der für PHP-5.3 und höher geschrieben wird MUSS formale Namespace nutzen.
Beispiel:
<?php // php 5.3 und später: namespace Vendor\Model; class Foo { }
<?php // php 5.3 und später: namespace Vendor\Model; class FooInterface { }
Das Term 'Klasse' bezieht sich auf alle Klassen, Interfaces und Traits.
Klassenkonstanten MÜSSEN vollständig in Großbuchstaben deklariert werden. Der Unterstrich trennt einzelne Worte.
<?php namespace Vendor\Model; class Foo { const VERSION = '1.0'; const DATE_APPROVED = '2014-08-12'; }
Dieser Leitfaden vermeidet absichtlich jede Empfehlung in Bezug auf die Verwendung von $StudlyCaps, $camelCase oder $under_score Eigenschaftennamen.
Welche Namenskonvention auch benutzt wird, sie SOLLTE konsistent in einem vertretbaren Rahmen angewendet werden.
Anpassung an WB: Es MUSS durchgehend überall das StudlyCaps Format benutzt werden, wobei jedem Bezeichner ein Kleinbuchstabe vorangestellt wird, der den Datentyp der Eigenschaft beschreibt. Derzeit definiert sind folgende Zuweisungen:
's' ⇒ String, 'i' ⇒ Integer/Ganzzahl, 'f' ⇒ Fließkommazahl, 'b' ⇒ boolean, 'a' ⇒ Array, 'o' ⇒ Objekt, 'c' ⇒ Callback, 'm' ⇒ mixed, 'r' ⇒ Resource
$sItemName = 'Something'; $iUserId = 2; $fPrice = 45.25;
Methodennamen MÜSSEN in camelCase() deklariert werden.
— Manuela v.d.Decken 12.08.2014 20:35