Das Dokument behandelt Best Practices für die Programmierung in PHP, einschließlich Kommentierung, Formatierung und Strukturierung von Code, sowie Methoden zur Verbesserung der Wartbarkeit. Es stellt Prinzipien wie SOLID und KISS vor und thematisiert technische Schulden sowie empfohlene PHP-Tools zur Code-Analyse und -Verwaltung. Zudem bietet es Hinweise zur Verwendung von Versionskontrollsystemen und zur Dokumentation.

1. PHP
Personal Homepage Tools - Hypertext Preprocessor
Programmieren für das Web
Teil 3 - Qualität und Standards
Version: 2012-05-15
License: CC BY NC SA
Erstellt von Hans-Joachim Piepereit (hajo_p@live.de)
Konstruktives Feedback hierzu ist gern gesehen

2. Inhaltsverzeichnis
1 Kommentare 3
2 Formatierung 5
3 Struktur 8
3.1 Grundlagen und Gestaltung . . . . . . . . . . . . . . 8
3.2 Wartung verbessern mit SOLID und LoD . . . . . . . 11
3.3 Technische Schulden . . . . . . . . . . . . . . . . . . 13
4 Software Projekte 14
4.1 PHP Tools . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Verwaltung und Übersicht . . . . . . . . . . . . . . . 17
5 Anhang 18
5.1 Verweise und Empfehlungen . . . . . . . . . . . . . . 18
2

3. 1 Kommentare
Wo wird kommentiert?
- Zuständigkeit der Datei am Beginn dieser beschreiben
- Konstrukte wie z.B. Klassen, Methoden und Attribute erklären
- Programmfluss beschreiben, um diesen nachvollziehbar zu machen
- Unfertige Bereiche mit Meta-Tags wie z.B. @TODO oder @FIXME
Wie wird kommentiert?
- Einheitliche Sprache, International bietet sich Englisch an
- Nicht den Code wiederholen, sondern einen Mehrwert schaffen
Blöcke /** **/
Einzeiler //
Ungenutzer Programmcode
3

4. Warum wird kommentiert?
- Schnellere Einarbeitung für andere Personen und die spätere Pflege
- Generierung einer API Dokumentation mit z.B. phpDocumentor
1 <?php // B e i s p i e l e i n e s Datei−I n f o−Kommentar−B l o c k e s :
2 /∗∗
3 ∗ This f i l e does some kind o f magic
4 ∗
5 ∗ PHP V e r s i o n 5
6 ∗
7 ∗ @category Magic
8 ∗ @package Example
9 ∗ @author Hans−Joachim P i e p e r e i t <hajo_p@live . de>
10 ∗ @copyright 2012 Hans−Joachim P i e p e r e i t
11 ∗ @license http : / / creativecommons . org CC BY NC SA
12 ∗∗/
4

5. 2 Formatierung
Einrückung
Wo wird eingerückt?
Je Abschnitt bzw. logischem Unterbereich
1 <?php
2 {
3 // H ie r i s t e i n e i g e n e r U n t e r b e r e i c h
4 }
Wie wird eingerückt?
- Mit 4 Leerzeichen, (Tabs als 4 Leerzeichen im Editor einstellen)
- Keine Tabs (bringen Probleme mit bei Patches, Diffs, usw.)
5

6. Warum wird eingerückt?
- Gleichmäßiger Lesefluss und bessere Lesbarkeit
- Abschnitte wie z.B. Schleifen leichter erkennbar
Maximale Zeilenlänge
- Sollte zwischen 75 und 85 Zeichen liegen, Einrückung inklusive
- Erspart das Scrollen bzw. Umbrechen von Zeilen im Editor
- Verhindert das Schachteln zu vieler Abläufe je Zeile
PHP Tags
Kein "Short open tag" verwenden (<? und bis 5.4 auch <?=)
Nur <?php verwenden und kein "Closing tag" am Dateiende (?>)
6

7. Dateiformat
- Vorzugsweise als ASCII bzw. ISO oder UTF-8 abspeichern
- Kein BOM (Byte order mark) aktivieren bzw. verwenden
- Zeilenumbrüche nach Unix-Art per LF bzw. "n"
- Kein CR bzw. "r" verwenden (Achtung bei Windows vor CRLF)
Namensgebung im Quelltext
- Sprechende, sinnvolle und unabgekürzte Namen verwenden
- Klassen beginnen immer mit einem Großbuchstaben
- Alles mit Sichtbarkeit "private" beginnt mit einem Unterstrich (_)
- Für "protected" usw. ist der Unterstrich zu Beginn nicht erlaubt
Funktionen und Methoden
- Beginnen mit einem Kleinbuchstaben, z.B. getMyData()
- In der Folge beginnt jedes Wort mit einem Großbuchstaben
7

8. 3 Struktur
3.1 Grundlagen und Gestaltung
Kohäsion
- Jede Programmeinheit ist in eine eigene Klasse geschachtelt
- Jede Aufgabe ist darin in einer eigenen Methode platziert
- Starke Kohäsion erleichtert die Wartung und Pflege von Software
DRY - Wiederhole dich nicht
- Redundanz sollte vermieden oder zumindest reduziert werden
- Verringert die Anzahl und Wartung von Duplikaten
- Es hilft bei der Wahrung von Zuständigkeiten in der Software
- Weniger Code bedeutet weniger Arbeit und bessere Übersicht
8

9. KISS - Bevorzuge einfache Lösungen
- Komplexe Lösungen sind meist nur schwer durchdringbar
- Je einfacher ein Problem gelöst werden kann, umso besser
- Klein beginnen und bei Bedarf erweitern (Minimalismus)
Konvention über Konfiguration
- Benenne und gestalte so viel wie möglich in einheitlicher Form
- Gehe vom Normalfall aus und Konfiguriere nur die Abweichungen
- Verringert den Umfang und Aufwand für Konfiguration + Wartung
OOP - Objektorientierung
- Nicht alles muss zwangsläufig ein eigenes Objekt sein
- OOP in PHP ist eher statisch, kann auch so verwendet werden
- Singletons zeigen oftmals, dass dies nicht verstanden wird
- Workarounds für fehlende Features bringen zu viel Aufwand mit
9

10. Vertragsmodell
- Bei der Interaktion mit einem Objekt schließt man einen Vertrag
- Das Objekt sichert dabei zu, wie es auf Anfragen antwortet
- Der Anfrager muss dafür die Vorbedingungen einhalten
- Durch definierte Fehler werden Folgefehler und Probleme vermieden
- Das Verhalten der Software kann man dadurch leichter vorhersagen
Sichtbarkeit von Daten
- Alles nicht für die Interaktion notwendige wird verborgen
- Beispiel: "private" und "protected" bei Attributen und Methoden
- Kapselung schirmt das Objekt besser von äußeren Einflüssen ab
- Führt zu besseren Schnittstellen und zielgerichteter Interaktion
10

11. 3.2 Wartung verbessern mit SOLID und LoD
S - Single Responsibility
- Es sollte nie mehr als einen Grund geben eine Klasse zu ändern
- Verlang einen starken Bezug zwischen Methoden und ihrer Klasse
- Soll z.B. durch Redundanz erzeugte Wartungsfehler verhindern
O - Open Closed Principle
- Halte Module offen für Erweiterungen (z.B. Vererbung anbieten)
- Verbiete Modifikationen am Verhalten oder gar der Schnittstelle
L - Liskov Substitution Principle
- Subklassen sollten sich wie Superklassen verhalten
- Dadurch sind diese Austauschbar und die Vererbung resistenter
- Unerwartetes Verhalten und Verletzungen später schwer Auffindbar
11

12. I - Interface Segregation
- Interfaces sollten nur das für ihre Verwendung nötige enthalten
- Zu große oder generische Interfaces sind in kleinere zu zerlegen
D - Dependency Inversion Principle
- Hohe Ebenen sollten nicht von niedrigen Ebenen abhängen
- Abstraktionen sind es, wovon diese Module abhängen sollten
- Abhängigkeiten verlaufen damit nur in genau eine Richtung
- Vermeidet zyklische bzw. reduziert allgemeine Abhängigkeiten
LoD - Gesetz von Demeter
- Da sinnvoll, wo Vermittler (Wrapper) den Vorteil nicht zerstören
- Liefert eine Möglichkeit die Kopplung zwischen Objekten zu messen
- Objekte sollten nur mit ihrer direkten Umgebung kommunizieren
- Beteilige so wenig Programmteile wie Möglich (Verschwiegenheit)
12

13. 3.3 Technische Schulden
- Gewollte bzw. geplante Schulden bei der Qualität der Software
- Sind dazu da z.B. Meilensteine noch rechtzeitig zu erreichen
- Sollten in jedem Fall dokumentiert und nachgeholt werden
- Mit der Zeit wird das Aufholen zunehmend schwieriger
Ursachen
Eingeplant, fehlende Zeit, fehlende Kenntnisse oder Erfahrungen,
unzureichende Kommunikation, parallele Entwicklungsprozesse,
unterlassene Überarbeitung von veraltetem Code (Refactorings)
Beispiele
Fehlende Dokumentation oder Tests, Abweichungen von Standards,
hohe Komplexität im Code, viele Redundanzen, enge Kopplungen,
aber auch fehlende Sicherungen, Versionierung oder notwendige Tools
13

14. 4 Software Projekte
4.1 PHP Tools
Xdebug
http://www.xdebug.org
- PHP Erweiterung für Debugging und Profiling
- Auch mit Editoren wie z.B. Eclipse oder NetBeans verwendbar
CodeSniffer
http://pear.php.net/package/PHP_CodeSniffer
- Durchsucht PHP Quelltext nach Abweichungen gegenüber Regeln
- Regeln wahlweise aus Vorlagen (z.B. PEAR) oder XML Datei
14

15. PHP Copy Paste Detector
http://github.com/sebastianbergmann/phpcpd
- Durchsucht PHP Quelltext nach dupliziertem Inhalt
PHP Depend
http://pdepend.org
- Statische Code Analyse für Software Metriken
- Zeigt z.B. zyklomatische Komplexitäten an
PHP Documentor
http://phpdoc.org
- Generiert eine API Dokumentation aus Kommentaren
- Version 2 hieß vormals DocBlox und ersetzt das uralte 1.x
15

16. PHP Lines of Code
http://github.com/sebastianbergmann/phploc
- Zählt die Zeilen und andere statistische Werte im Code
PHP Mess Detector
http://phpmd.org
- Sucht im Code nach möglichen Fehlern und suboptimalen Inhalten
- Findet auch ungenutzte Variablen, Methoden, usw.
PHP Unit
http://github.com/sebastianbergmann/phpunit
- Unit Test Framework für PHP mit vielen Möglichkeiten
- Kann um Code Coverage Metriken ergänzt werden
16

17. 4.2 Verwaltung und Übersicht
Versionskontrolle
- Es sollte so etwas wie Git oder Subversion verwendet werden
Jenkins for PHP
http://jenkins-php.org
- Vereint die meisten oben genannten Tools an einer Stelle
- Jenkins ist ein Java basierter Continuous Integration Server
- Empfehlung: phpDox durch phpDocumentor2 austauschen
Sonar mit PHP Plugin
http://www.sonarsource.org
- Software Analyse zu Coding Rules, Tests und anderen Metriken
- Die generierten Reports sagen viel über die Software aus
17

18. 5 Anhang
5.1 Verweise und Empfehlungen
Websites zu den Themen
http://pear.php.net/manual/standards.php PEAR Coding Standard
http://martinfowler.com Martin Fowler
http://www.objectmentor.com Object Mentor (RCM)
Bücher zu den Themen
PHP Design Patterns Stephan Schmidt
Software Qualität in PHP Sebastian Bergmann
PHP Projects with Jenkins Sebastian Bergmann
Patterns of EAA Martin Fowler
Clean Code Robert C. Martin
18