Die CopyPaste Detection für PHP (phpcpd) ist eine wunderbare Sache und lässt sich einfach aufrufen und in phpUnderControl integrieren. Doch die Stellen zu suchen und zu Eliminieren kann schon etwas mühsam sein. Deutlich einfacher geht es mit dem Eclipse Plugin:  PHP Tool Integration. Hier kann man seit kurzem nicht nur den CodeSniffer innerhalb von Eclipse nutzen, sondern auch die CopyPaste Detection.

Das Tool lässt sich einfach über das Context Menü aufrufen:

Im Editor werden dann die Fehler angezeigt:

Zur Installation sollte man diese Eclipse Update Seite verwenden:

http://www.phpsrc.org/eclipse/pti/

Danach muss man noch die Einstellungen anpassen und die PHP Executable und die PEAR Libary anpassen:

Ich nutze die Eclipse PHP Tool Integration Tools jetzt standardmäßig wegen der guten  Code Sniffer Integration wie bereits in einen älteren Blogbeitrag beschrieben.

Darüber hinaus beinhaltet das Eclipse Plugin auch eine Funktion zum schnellen Ausführen von Unit Tests.

Wenn man an einen Unit Test arbeitet kann man einfach einen Button im Eclipse anklicken zum Ausführen des Tests.

Erstmal ist das relativ unspannend, da das selbe passiert wie bei einem Kommandozeilen Aufruf und die Ausgabe nur  unschön in der Eclipse Console erscheint.

Es spart aber immerhin einen Toolwechsel und einige Klicks.

Wirklich praktisch finde ich aber die Auswertung der Fehler im Editor von Eclipse. Dort wird die Stelle wo der Fehler aufgetreten ist als unterstrichener Fehler markiert.

Es wird nicht nur die Stelle im Test markiert sondern Fehler die in den getesteten Code Aufgetreten sind. Wenn dort ein PHP Fehler auftritt oder eine Exception geworfen wird die nicht abgefangen wird, wird diese Stelle markiert. So braucht man nicht anhand der Zeilen Nummern die Stellen suchen.

Bei der Erstellung der Codecoverage mit phpUnit bin ich schon mehrmals aus diesen PHP Fehler gestoßen:

PHP Fatal error:  Cannot redeclare class

Aus dem Code war kein Grund dafür ersichtlich da alle Dateien mit require_once eingebunden waren. Das Problem lag dabei in der Verwendung von Mock Klassen ohne diese vorher importiert zu haben.

Ich kann mit folgenden Code eine Object der Klasse Example erstellen ohne die original Klasse zu laden.

$object = $this->getMock ( 'Example', array (), array (), '', false );

Wenn danach die original Klasse Example importiert wird, ist diese schon deklariert und es kommt zu diesen Fehler. Abhilfe tut hier ein require_once im Test:

require_once('path/to/Example.php');
$object = $this->getMock ( 'Example', array (), array (), '', false );

Dann klappt es auch mit der Coverage Auswertung.

Leider gibt es in den PHP Tools für Eclipse einen kleinen Bug unter Windows wenn man ein eigenen Coding Standard verwenden will. Der PHP_CodeSniffer kann mit dem Parameter –standard aufgerufen werden und der CodeSniffer sucht in dem Pfad nach Sniff Dateien. Der CodeSniffer verwendet dafür die PHP Konstante DIRECTORY_SEPARATOR die ja bekanntlich unter Windows ein \ ist und kein /. Jetzt sollte man unter Windows den CodeSniffer wie folgt aufrufen:

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.

Sebastian Bergmann hat mit phploc ein kleines Tool geschaffen, das einem ein kurzen Überblick über die Beschaffenheit des PHP Projektes gibt. Im Gegensatz zu PHP_Depend beschränkt sich die Auswertung auf ein paar werte, die aber für eine Auswertung innerhalb eines continues integration Prozess ausreichen würde. Es eignet sich nicht um die Schwachstellen zu finden.

Sinnvoll ist es auch zu zur Prüfung ob ein Opensource Projekt den eigenen Ansprüchen genügt oder ob ein schlechter Code zu erwarten ist mit dem man auf Dauer nicht arbeiten kann.

phploc wird einfach über den PEAR Installer installiert und kann dann über die Komandozeile über diesen Befehl aufgerufen werden.

> phploc "C:\...."

Ich habe ein bekanntes Projektmanagementtool mit diesen Tool getestet und folgendes Ergebnis bekommen.

Auffällig ist das hier keinerlei Interfaces und Abstrakte Klassen verwendet werden. Der Code ist relativ gut dokumentiert. Die Methoden haben mit durchschnittlich 36 Zeilen zu viel Logik und auch die Cyclomatische Komplexität ist etwas zu hoch. Der hohe Anteil an öffentlichen Methoden sprechen für eine potentielle Instabilität. Dafür scheint die Package Struktur übersichtlich zu sein.

Das PHP Pear Packet “PHP_Depend” eignet sich hervoragent zur Analyse der Code Qualität des eigenen PHP Projekts. Es lässt sich einfach über den Pear Installer installieren und kann dann auf der Comando Zeile über den Befehl “pdepend” aufrufen. Es wird nur PHP benötigt und kein Webserver oder Datenbank. Eine Installation unter Windows war ohne Probleme möglich.

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.

In der neuen Typo3 Version 4.3 existiert eine neue Klasse t3lib_PageRenderer in der die CSS und Javascript Dateien registriert werden können. In dieser Klasse ist es vorgesehen die CSS Dateien zu bündeln und zu komprimieren. Da diese Funktionen noch nicht implementiert sind und es aber die Möglichkeit für Hooks gibt habe ich die Extension js_css_optimizer erstellt, die diese Lücke füllt.

Die Extension registriert folgende Hooks:

• cssCompressHandler – zum Komprimieren der CSS Dateien
• jsCompressHandler – zum Komprimieren der JavaScript Dateien
• concatenateHandler – zum Bündeln der Dateien
• clearCachePostProc – zum Löschen der gecachten Dateien im typo3temp Verzeichnis

CSS Komrpimierung

Hierbei wird das Tool CSSTidy verwendet.  Die Konfiguration lässt sich über den Extension Manager in Typo3 einstellen.

Die CSS Datei wird in einem neuen Verzeichnis abgelegt. Die Extension versucht dabei die relativen Pfade in der CSS Datei auf Bilder um zuschreiben. Hier ist eventuell noch Anpassungbedarf.

Damit die CSS Datei komprimiert wird muss folgender Typo Script Code ergänzt werden:

page {
includeCSS {
 screenStyle = ..../base.css
 screenStyle {
   media = screen
   import = 0
   compress=1
 }

JavaScript Komprimierung

Für das JavaScript wird die JSMin Klasse aus dem Typo3 Core verwendet. Es wird nicht die t3lib::minify… verwendet, da diese nicht so effektiv ist.

In TypoScript kann die Komprimierung einzeln ein und ausgeschaltet werden:

page{
 includeJS {
 file1 = ....common.js
 file1.compress=1
...

Bündelung

Die Bündelung der Javascripte und CSS Dateien kann über TypoScript aktiviert werden.  Dafür gibt es diese Einstellung:

config.concatenateJsAndCss = 1

Hierbei ist nicht möglich CSS und JavaScript unterschiedlich zu behandeln. Deshalb gibt es in der Extension die Möglichkeit über den Extension Manager die Bündelung beispielsweise für CSS auszuschalten.

Wenn bestimmte Dateien auf jeder Seite benötigt werden, dann macht es Sinn diese als Libs einzubinden. Dafür gibt es im TypoScript die Option includeJSlibs.

page.includeJSlibs{
  jquery = ...jquery-1.3.2.min.js
  ...
}

Dann werden die in eine separate Datei geschrieben und können vom Browser separat gecacht werden.

Caching

Die komprimierten und gebündelten Dateien werden in dem typo3Temp Verzeichnis abgelegt. Die Cache Datei werden nicht erneuert sondern müssen gelöscht werden um neu erzeugt zu werden. Das Löschen passiert automatisch wenn im Typo3 Backend der Cache gelöscht wird.

Javascript und CSS aus den Plugins hinzufügen

Wenn man früher in einem Plugin JavaScript oder CSS Daten hinzufügen wollte ohne TypoScript hat man das über $GLOBALS['TSFE']->additionalHeaderData machen. Da diese Daten nicht als JS oder CSS deklariert sind nutzen sie in diesen Kontext nichts mehr.  Man kann jetzt mittels $GLOBALS['TSFE']->getPageRenderer() auf den PageRenderer zugreifen und diesen die JS und CSS Dateien bekannt machen. Wenn man mit dem PageRenderer arbeitet kann man auch die Vorteile der Komprimierung und Bündelung nutzen. Es lohnt sich deshalb die Klasse t3lib_PageRenderer genauer anzuschauen.