Download Coding Standard
PHP Coding Standard
Wenn man dem Extreme Programming folgt, ist die Einhaltung eines Coding Standards ein wichtiger Bestandteil der gesamten Projektarbeit. Darüber hinaus gibt es jedoch auch andere wichtige Faktoren:
- Kommunikation
- Urlaubsvertretung
- funktionierender Code
- übersichtlicher Code
- Module und Modultests
- Wiederverwendbarkeit des Codes
- einfache Wartung des Codes
- Code, der leicht zu erweitern ist
- Unterstützung von Refactoring
um nur einige zu nennen. Bis auf den Punkt "Kommunikation" unterstützt ein Coding Standard alle genannten Punkte. Selbst die Urlaubsvertretung wird einfacher, denn wenn jeder den Code des anderen versteht, kann man auch schnell Bug-Fixes vornehmen oder Module des anderen verwenden ohne das Rad neu zu erfinden.
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
Zitat von Martin Fowler ("Refactoring - Improving the design of existing code", Seite 15)
Um diese Ziele zu erreichen, muss eine PHP-Applikation
- leicht zu lesen sein
- leicht verständlich sein
- gut dokumentiert sein
- durch verschiedene Programmierer wartbar
- frei von typischen Fehlern
sein. Im besten Falle kann sogar ein Kunde die Module der PHP-Applikation verstehen und weiter verwenden. Wenn man das nicht möchte, so ist die logische Schlussfolgerung nicht Kommentare und Struktur wegzulassen, sondern den PHP-Code zu verschlüsseln, zum Beispiel mit dem Zend Guard oder dem PHP Encoder.
Das Ziel von leicht verständlichem Source-Code ist erreicht, wenn jedes Mitglied des Teams, jedes Modul aus dem Stehgreif erklären kann. Nicht zuletzt soll jede Arbeit am Projekt, dem Code und der Dokumentation Spaß machen. Je höher der Frustfaktor ist, je unübersichtlicher Strukturen und Code sind, desto höher ist die Wahrscheinlichkeit, das die Arbeit keinen Spaß mehr macht. Das gilt es auf jeden Fall zu verhindern.
Regeln und Empfehlungen des PHP Coding Standard
Die Regeln und Empfehlungen des PHP Coding Standard wurden mit AurigaDoc erstellt, um auch ein PDF zur Verfügung stellen zu können.
- Vorwort
- Sinn und Zweck eines Coding Standard
- Regel 0: Immer wenn eine Regel gebrochen wird, muss das deutlich und erkennbar dokumentiert werden
- Regel 1: Das Prinzip der Einfachheit: Don't make me think!
- Regel 2: Dateien, die inkludiert werden, sollten mit "*.inc.php" enden oder in einem Unterverzeichnis liegen
- Regel 3: Jede PHP-Datei muss das Copyright und einen Kommentar enthalten, der die Funktionalität beschreibt
- Regel 4: Die Sprache für Kommentare und Bezeichner sollte Englisch sein
- Regel 5: Jede Datei wird mit Änderungskommentaren und einem Zeitstempel versehen
- Regel 6: Jede Funktion muss mit Kommentaren versehen werden
- Regel 7: Lange Kommentare sollten mit /* und kurze mit // gemacht werden
- Regel 8: Alle Bezeichner werden aussagekräftig und eindeutig definiert
- Regel 9: Benennung von Variablen und Funktionen erfolgen mit Unterstrich und in Kleinbuchstaben
- Regel 10: Konstanten werden in Großbuchstaben defniert
- Regel 11: Auf keinen Fall Abkürzungen verwenden, die zweideutig sein können
- Regel 12: Funktionen, Parameter und Rückgabewerte gut dokumentieren
- Regel 13: Die Klammern für eine Funktion () stehen direkt am Funktionsnamen
- Regel 14: Funktionen mit langen oder vielen Parametern müssen übersichtlich strukturiert werden
- Regel 15: Der Code muss vom Design getrennt werden (Template Engine)
- Regel 16: Alle Templates müssen validiert werden
- Regel 17: Bezeichner einer Klasse werden mit Großbuchstaben voneinander getrennt
- Regel 18: Keine magischen Zahlen
- Regel 19: SQL-Befehle werden groß geschrieben
- Regel 20: Variablen in Zählschleifen werden mit einem Buchstaben definiert
- Regel 21: Trinitäts-Operatoren dürfen nicht verschachtelt werden
- Regel 22: Trinitäts-Operatoren müssen Klammern enthalten
- Regel 23: INSERT-Anweisungen müssen die einzelnen Spalten für die VALUES-Klausel enthalten
- Regel 24: Code, der nicht benutzt wird, muss gelöscht werden
- Empfehlung 1: Geschweifte Klammern werden im Allman-Stil eingerückt
- Empfehlung 2: Jede Kontrollstruktur hat einen Block mit Klammern
- Empfehlung 3: Zum Einrücken von Quellcode werden Tabulatoren verwendet
- Empfehlung 4: Die Benutzung von Zahlen in Bezeichnern ist zu vermeiden
- Empfehlung 5: Es sollte Subversion und ein Bugtracker-System benutzt werden
- Empfehlung 6: Keine Anführungsstriche bei String-Deklarationen
- Empfehlung 7: Debug-Informationen von Anfang an einbinden
- Empfehlung 8: Werte für FOR-Schleifen richtig setzen
- Richtig und Falsch 1: Klammern setzen und Abkürzungen
Weitere Regeln und die Empfehlungen sind in Arbeit. Außerdem wird es Kapitel mit "Richtig und Falsch" geben.
Motivation
Als ich auf einer PHP-Mailingliste eine Diskussion mitbekam, wie unsicher PHP doch ist, habe ich über alle Fremdprojekte nachgedacht, mit denen ich je gearbeitet habe. Das Ergebnis war:
- keine Strukturen
- keine Dokumentation des Codes
- überlange Skripte, Funktionen und Methoden
Die Folge sind Aussagen wie:
"Ich bin froh, dass meine Banksoftware nicht mit PHP programmiert wurde."
"PHP ist was für Skript-Kiddies!"
Aber wie viele private, dedizierte und Root-Server setzen das Hardened-PHP Project ein? Wie viele PHP-Programmierer beschäftigen sich mit Sicherheitsfragen und -standards, bevor sie mit einem Projekt beginnen?
Ich glaube nicht, dass PHP unsicher ist. Ich glaube nur, dass es viele, viele unsichere PHP-Programmierer gibt, das ist aber nicht die Schuld von PHP.
Diese Seite wurde mit dem Ziel - und der Hoffnung - erschaffen, dass immer mehr Skripte bei hotscripts.com einem Coding Standard unterliegen.