phpcs --standard=C:\path\to\standard

Wenn man aber bei den PHP-Tools in die Debug Ausgabe schaut wird folgender Befehl ausgeführt

phpcs --standard=C:/path/to/standard

Dadurch findet der CodeSniffer die Dateien nicht.

Ich habe den Bug gemeldet und hoffe das es bald behoben ist.

Als Workaround habe ich den CodeSniffer innerhalb des PEAR Packet angepasst und folgende Zeile ergänzt:

PHP\CodeSniffer.php Zeile 400

$this->standardDir = str_replace('/',DIRECTORY_SEPARATOR,$this->standardDir);

In Eclipse muss man dann noch bei den PHP-Tools Einstellungen die lokale PEAR Libary verwenden.

Man kann PHP_Depend über einen beliebigen Code Ordner laufen lassen und sich dabei verschiedenen Formate ausgeben lassen.

JDepend ist ein Format aus der JavaWelt und wohl auch für den Namen des Projektes verantwortlich

JDepend traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.

• –jdepend-chart=….svg Erzeugt eine SVG Grafik die die Instabilität in Abhängigkeit zur Abstraktion anzeigt
• – jdepend-xml=…xml Gibt diese Informationen als XML Datei aus

Es gibt auch eine reine XML Ausgabe,  in der die Ergebnisse für jede einzelne Datei steht

• –summary-xml=….xml

Spannend ist auch die Pyramiden Darstellung

• –overview-pyramid=….xml

@package

Wenn man in seinen PHPDoc Kommentaren nicht mit dem @package Element gearbeitet hat muss man den Parameter –bad-documentation angeben. Lässt man den weg wird entweder gar nichts erzeugt oder nur für die Dateien die diesen Element besitzen. Um ordentlich mit dem Tool arbeiten zu können, sollte man @package ergänzen.

Typo3 Vergleich

Ich habe man den Kern von Typo3 Version 4 und 5 mit dem Tool analysiert:

JDepend Chart:

Typo3 4

Typo3 5

Überblick:

Typo3 4

Typo3 5

Aussagekräftig ist dieser Vergleich natürlich noch nicht, da Version 5 noch kaum Code enthält, aber man kann einen deutliche besseren Code erkennen.

Beispielsweise kann es sein das nach einen Login verschiedene Dinge geprüft werden müssen. Zusätzlich sollen vielleicht noch Aktionen geloggt werden.

Wenn man jedesmal den Code für den Login erweitern würde, dann hätte man innerhalb kürzester Zeit eine riesige Klasse mit schwer wartbaren Code.

Bei dem Observer Pattern gibt eine Anwendung nur bekannt das ein bestimmtes Ereignis (Event) stattgefunden hat. Andere Programmteile können sich von außen an den EventDispatcher anmelden und werden dann von diesen benachrichtigt wenn das Ereignis eintritt.

In der PHP Bibliothek PEAR gibt es dieses Pattern schon fertig programmiert: Event_Dispatcher.

1. Handler erstellen

Als Erstes benötigt man einen Handler der das Ereignis verarbeitet.

class Handler{
/**
* @param    Event_Notification
*/
public function getOnlogin(Event_Notification $oEvent_Notification){
$oValueObjects_User = $oEvent_Notification->getNotificationObject();
$aInfos = $oEvent_Notification->getNotificationInfo();
// mach irgendetwas
}
}

2. Handler registrieren

Jetzt muss der Handler beim Event Dispatcher registriert werden.

require_once 'Event/Dispatcher.php';
$oEvent_Dispatcher = Event_Dispatcher::getInstance();
$oEvent_Dispatcher->addObserver(array(new Handler(),'onLogin'),'onLogin');

Der erste Parameter ist ein PHP Callback. Als dritten Parameter kann man von eingrenzen von welche Objekten dieser Event geworfen werden darf.

3. Ereignis auslösen

Jetzt muss das Ereignis noch ausgelöst werden.

require_once 'Event/Dispatcher.php';
Event_Dispatcher::getInstance()->post($this,'onLogin',$aInfo);

Im dritten Parameter kann man noch Informationen in Form eines Array übergeben.

Nutzen

Veränderung vermeiden

Der Nutzen in dem Pattern liegt darin das man die Anwendung nicht mehr nachträglich anpassen muss um Erweiterungen einzubauen.

Verantwortlichkeiten sauber trennen

Die Verantworltichkeit der Kompontenten bleibt frei von Nebensächlichkeiten. Zum Beispiel kümmert sich dann die Login Komponente nur um das Login und sonst nichts. Alles andere wird über die Events abgearbeitet.

Fazit

Ich verwende dieses Pattern sehr viel und es macht die Anwendung wartbarer und den Einbau von Erweiterungen einfacher. In anderen Sprachen wie .NET ist das Pattern bereits in die Sprache eingebaut.