2009-06-11 8 views
52

Ich arbeite mit der Idee, PHP CodeSniffer auf unserem Continuous Integration Server einzurichten, um die Qualität unserer Code-Basis zu verbessern. Nach dem Lesen der Dokumentation bin ich sehr gespannt auf die Idee, unsere Programmierstandards zu normalisieren und durchzusetzen. Ich wundere mich jedoch über die tatsächliche Verbesserung unseres Produkts. Mir ist durchaus bewusst, dass der Sniffer nur Verstöße gegen einen definierten Codierungsstandard erkennt, aber welche Vorteile bietet eine saubere, konsistente Codebasis? Lohnt es sich, ein Projekt mit mehr als 100.000 Codezeilen zu refaktorieren, um dem PEAR-Standard zu entsprechen?Wie nützlich ist PHP CodeSniffer? Code Standards Durchsetzung im Allgemeinen?

Für diejenigen, die mit PHP CodeSniffer nicht vertraut sind oder Code-Geruch im Allgemeinen, hier ist ein Beispiel für die Ausgabe:

DATEI: /path/to/code/myfile.php
5 Fehler gefunden (S) BEEINTRÄCHTIGUNG 2 LINE (S)
-
2 | FEHLER | Fehlender Dateidoc-Kommentar
20 | FEHLER | PHP-Schlüsselwörter müssen Kleinbuchstaben sein; erwartet "falsch" aber gefunden "FALSCH"
47 | FEHLER | Zeile nicht korrekt eingerückt; erwartet 4 Plätze aber gefunden 1
51 | FEHLER | Fehlende Funktion doc Kommentar
88 | FEHLER | Zeile nicht korrekt eingerückt; 9 Räume erwartet, aber gefunden 6

Streng genommen ist der Anwender/Kunde würde einen Unterschied in einem Produkt nicht feststellen, dass Refactoring wurde standardkonform sein, aber ich frage mich, ob es noch andere versteckte Vorteile

Im Moment ist unser Code keineswegs schlampig und wir versuchen unseren eigenen persönlichen Standards zu folgen, die zum größten Teil von Pear's Coding Standards abgeleitet sind, aber ein geschultes Auge kann die Unterschiede erkennen.

Also meine Frage ist, wie viel verbessern sie die Qualität eines Produkts. Welche latenten Vorteile ergeben sich daraus?

Bin ich gerade zwanghaft mit meinem Wunsch, unser Produkt näher an eine Reihe von Standards zu bringen? Wäre es das wert? Wenn ja, mit welcher Strategie haben Sie den Code-Sniffer implementiert und die erkannten Verstöße korrigiert?

+7

Es erstaunt mich immer wieder, wie ich scheinbar gute, informative Fragen zu SO finde, die "als nicht konstruktiv" geschlossen werden. –

Antwort

32

Coding Style Conventions zu verwenden ist eine gute Idee, weil es Entwicklern hilft, sich nicht von Code abzulenken, der in einem anderen Stil geschrieben wurde, wenn sie an Code arbeitet, den sie nicht geschrieben haben. Es wird Ihre Code-Basis oberflächlich sauberer machen. Es ist großartig, wenn Sie es automatisieren können, aber es gibt normalerweise keine Notwendigkeit, große Längen zu durchlaufen, um zu entsprechen (es sei denn, der aktuelle Stil ist schrecklich). Wenn Sie bereits einen ausreichend guten Standard haben, bleiben Sie dabei.

Code-Geruch ist etwas anderes obwohl: es ist (eine Reihe von) Symptome, die ein tieferes Problem mit dem Code anzeigen können. Beispiele sind zyklomatische Komplexität, lange Methodennamen, große Klassen, nicht beschreibende Namen, doppelter Code usw. Dies ist normalerweise viel problematischer, da dies die Wartbarkeit Ihres Codes erheblich beeinträchtigen kann. Sie sollten diese Probleme auf jeden Fall lösen.

PHP CodeSniffer scheint hauptsächlich für die Überprüfung von Stilkonventionen entwickelt worden zu sein, nicht für den Code-Geruch. Wenn Sie es verwenden können, um Stilkonventionen durchzusetzen, großartig. Aber passen Sie auf, dass es Ihre Codebasis nicht wesentlich besser macht. Sie sollten manuelle Überprüfungen durchführen, um dies zu erreichen.

Wenn Sie wollen, es zu benutzen um zu überprüfen, ob Sie erfüllen Ihre aktuellen Standard , die möglich zu sein scheint, finden Sie in der Antwort auf die Frage: „Ich mit Ihrem Coding-Standards nicht einverstanden sind! Kann ich PHP_CodeSniffer erzwingen mein eigenes?" in their FAQ.

+0

Ich möchte darauf hinweisen, dass phpcs kommt mit einer Reihe von Sniff * speziell * Adressierung tatsächlichen [Code Gerüche] (http://en.wikipedia.org/wiki/Code_smells) geliefert und kann ganz einfach erweitert werden, um Gerüche zu erkennen du definierst dich selbst. – Potherca

0

Bieten Sie PEAR-Pakete für den öffentlichen Vertrieb über PEAR/PECL an? Wenn das so ist, dann sollten Sie wahrscheinlich an PEAR-Konventionen festhalten.

Ansonsten kann ich nicht sehen, dass es den großen Refaktor wert ist. Das Größte ist, sich auf einen Kodierungsstandard für Ihr Team zu einigen ... muss nicht der Standard von PEAR sein ... stellen Sie einfach sicher, dass einige Standardkonventionen durchgesetzt werden.

Zum Beispiel bin ich ein Fan der

function foo() { 

Format vs PEAR Standard ..

function foo() 
{ 

Unterm Strich nicht zu viele Sorgen über ihrer Standard entsprechen, wenn es wird eine Menge Arbeit sein, besonders wenn Sie die Pakete nicht auf PECL setzen.

6

Es gibt viele Fälle, die menschliche Beurteilung erfordern, und CodeSniffer hat keine.

Konsequente Klammern, Einrückung verbessern den Code. Platzmangel nach Kommas im Funktionsaufruf? Wahrscheinlich kann vergeben werden, aber das ist Fehler nach CodeSniffer.

IMHO gibt es viel zu viele Fehler von CS gemeldet. Selbst Projekte, die scheinbar fehlerfreien Code haben, können leicht in Tausende von CS-Problemen laufen. Es wird schnell ermüdend und fast unmöglich, all diese Probleme zu lösen, besonders wenn es sich um eine Mischung aus echten Problemen und zwanghaftem Unsinn handelt - beide gleichermaßen als FEHLER gekennzeichnet.

Sie sind vielleicht besser dran, CS zu ignorieren und Zeit für tatsächliche Verbesserungen des Codes (in Bezug auf Design, Algorithmen) und nicht nur für völlig oberflächliche Leerzeichen- und Kommentaränderungen (benötigt 1 Zeile isAlpha Funktion wirklich 8 Zeilen Kommentare) ? Ja, wenn Sie CS fragen).

CS kann zu leicht Polierwerkzeug werden.

+9

Ich denke, es lohnt sich darauf hinzuweisen, dass alle Einwände in Ihrer Antwort wirklich Einwände gegen einen bestimmten Kodierungsstandard (vermutlich Zend oder PEAR) sind, nicht gegen CodeSniffer selbst. Ich fand es * sehr * nützlich, einen neuen Standard für jedes Projekt zu erstellen, indem ich zwischen "generischen" Sniffs auswähle und auswähle und meine eigenen (sehr projektspezifischen) Sniffs schreibe. Dies ist wirklich der einzige vernünftige Ansatz, den ich für große Projekte mit Legacy-Code sehen kann (dass Sie nicht den Luxus haben, von Grund auf neu zu schreiben), und XML-Regelsätze + Ausnahmen haben dies viel einfacher zu verwalten gemacht. – Peter

+1

Stimme völlig mit Peter überein. Sicherlich werden die grundlegenden CS-Standards Ihren Anforderungen nicht gerecht. Sie müssen ein wenig Zeit aufwenden, um Regelsätze zu optimieren. Das Schreiben eigener Regeln folgt, da es ein bisschen mehr Fähigkeiten benötigt. –

3

Das ist definitiv eine gute Sache. Wir führen unsere von einem SVN-Hook, so dass der gesamte Code den Hausstandard (eine Modifikation von PEAR) bestehen muss, bevor er festgeschrieben werden kann (dies war eine der besten Entscheidungen, die ich je getroffen habe).

Natürlich funktioniert dies am besten für ein neues Projekt, wo es nicht viel Legacy-Code zum Konvertieren auf den neuen Standard gibt. Um dies zu ändern, ändern Sie Ihren SVN-Pre-Commit-Hook, um nur neue Zusätze zum Codesniffer auszuführen und Änderungen zu ignorieren. Sie können dies tun, indem Sie die Zeile:

$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0 

Dies wird den Hook-Skript beenden, wenn es nicht ein neuer PHP-Code zu analysieren. Daher müssen alle neuen Dateien dem Standard entsprechen und Sie können den Legacy-Code zu Ihrer eigenen Zeit auf den Standard bringen.

3

Beachten Sie, dass Sie bei Verwendung von Eclipse oder Zend IDE von automatischen Tools profitieren können, die die Einhaltung eines Standards kostengünstiger machen. Sie können auch ein Continuous Integration Tool wie Hudson oder PHPUndercontrol verwenden.

  • PDT ist ein cooler Editor für PHP
  • PDT-Werkzeuge sind einige Plugins für die PDT mit einem automatischen Formatierungstool
  • DTLK (Dynamic Toolkit Library) verwendet werden, können einige externe Skripte zu starten, um Ihre Dateien zu überprüfen .

Sie können auch einen Blick auf PHP Checkstyle, die ich denke, leichter (Disclaimer: Ich habe daran gearbeitet) zu konfigurieren ist

einige andere Tools sind auf der „Dokumentation“ Seite der Website aufgeführt .

+0

Super! Danke Tchule –

+0

Eine Möglichkeit, es von der Kommandozeile (argv) zu einem '$ _GET' oder' $ _POST' Befehl zu übergeben? –

1

CodeSniffer ist eine großartige Sache zu implementieren, aber Sie müssen wissen, wie man es benutzt. Sofern Sie einen bestimmten Codierungsstandard nicht einhalten müssen, weil Sie Ihre Arbeit an ein externes Projekt übergeben, können Sie Ihre eigenen Codierungsstandards vollständig definieren.

PHP CodeSniffer sollte dies sehr einfach für Sie machen, da es bereits viele einzelne Code-Sniffs gibt, die Sie in Ihre eigene Coding-Standarddefinition aufnehmen können und nicht von Grund auf neu schreiben müssen. Während du die Möglichkeiten der existierenden Codesniffers erkundest, kannst du am Ende eine Erweiterung zu einem existierenden Sniff oder Sniff schreiben, wenn du das Bedürfnis hast.

Wenn Sie mit CodeSniffer beginnen möchten, müssen Sie zuerst eine Reihe von Sniffs erstellen, die Ihren aktuellen Codierungsstandards vollständig entsprechen, und die resultierenden Fehler und Warnungen überprüfen. Wenden Sie keinen der vordefinierten Standards an, da dies höchstwahrscheinlich zu viele Fehler mit zu wenig Nutzen zur Folge haben wird, wenn sie behoben werden. Wenn Sie beispielsweise mit PHPDoc keine Dokumentation generieren, wäre es nicht sinnvoll, alle codesniffer-Fehler über fehlende PHPDoc-Tags und Kommentare zu erfüllen.

11

Zählen Sie mich zu denen, die CodeSniffer evangelisieren. Nachdem ich jahrelang sehr skeptisch war, benutze ich es jetzt bei jedem Projekt, an dem ich arbeite. Warum?

Als Grace Hopper und/oder Andrew Tanenbaum sagte einst,

Das Wunderbare an Standards ist , dass Sie so viele zur Auswahl haben.

Ebenso ist es fast immer eine schlechte Idee ™ Ihren eigenen Kodierungsstandard zu erstellen; Erstellen Sie eine umfassende genug, um alle Ihre Code zu decken ist hart, und, viel wichtiger, es wird nicht nach dem Geschmack der nächsten Person, um Ihren Code zu pflegen, wer wird versuchen, Ihren Standard zu verbessern, so dass es ihm passt lang gehegter Programmierstil. Mit einem geeigneten externen Standard, ob es Zend oder PEAR oder Kohana oder JoeBobBriggsAndHisFifthCousin ist, können Sie sich auf die Inhalt statt der Formatierung konzentrieren. Besser noch, Tools wie PHP CodeSniffer unterstützen entweder den Standard "frisch aus der Dose" oder diejenigen, die vorher gegangen sind, haben fast sicher Support als Add-On implementiert.

Das Mischen von Codierungsstandards mit existierendem Code, der nicht in diesen Standard geschrieben wurde, wird Ihnen passen, es sei denn, Sie verwenden zwei einfache, komplementäre Regeln.

Dateien ausschließen, die Ihre Annahme des Codierungsstandard predate von geprüft wird, durch die --ignore Befehlszeilen Option oder eine gleichwertige Konfigurationsdatei Einstellungen. Aber, wenn Sie ändern irgendein Teil einer Quelldatei, aktualisieren Sie die gesamte Datei auf entsprechen mit Ihrem gewählten Standard.

ich nur wrote a new blog post über diese Art von Sache.

+0

Tolle Punkte, danke Jeff. –

+0

Ich habe ausgeschlossene Dateien gefunden, die älter als meine Arbeit sind, um die beste für meine psychische Gesundheit zu sein. Zu neuen Klassen/Methoden notieren Sie einfach im DocBlock 'Hay, das ist nach diesem Standard codiert'. –

98

Erstens bin ich der Betreuer von PHP_CodeSniffer, also bin ich in diesem Bereich eindeutig voreingenommen. Aber ich habe auch in meinen 10 Jahren als PHP-Entwickler an einigen großen Codebasen gearbeitet, also hoffe ich, dass ich einige konkrete Gründe mitbringen kann, warum Codierungsstandards eine gute Sache sind. Ich könnte eine Blog-Serie zu diesem Thema schreiben, aber ich werde dir nur eine kleine Geschichte darüber erzählen, wie PHP_CodeSniffer zustande kam, damit du das Problem verstehen kannst, das das Tool für mich gelöst hat.

Ich habe an einigen großen CMS-Projekten gearbeitet. Der erste hatte einen Haufen Code und ein relativ kleines Entwicklerteam. Wir hatten keine Standards. Aber wir hatten keine wirklichen Probleme. Das Team war klein und blieb eine ganze Weile zusammen. Wir haben uns aneinander gewöhnt.

Dann haben wir ein neues CMS gebaut. Wir haben mit ein paar Entwicklern angefangen. Ich war damals Teil eines Teams von nur zwei Entwicklern. Auch hier haben Codierungsstandards uns keine Probleme bereitet. Ich und der andere Entwickler kamen aus dem gleichen Hintergrund und hatten bereits einige Richtlinien festgelegt, denen wir folgten. Wir brauchten PHPCS damals nicht.

Aber dieses Team wuchs zu einem Zeitpunkt Entwickler und erreichte schließlich 12 Vollzeit-Entwickler und etliche kamen und gingen. Einige kamen aus dem alten CMS und einige kamen von außerhalb des Unternehmens. Alle hatten unterschiedliche Hintergründe und einen anderen Entwicklungsansatz. Es war offensichtlich, wer welchen Code geschrieben hat, weil die Stile so unterschiedlich waren. Wann immer Sie an etwas Komplexem gearbeitet haben, mussten Sie sich zuerst an ihren Stil anpassen, weil es einfach nicht so war, wie Sie es gewohnt waren, Code zu sehen. Es ist, als würde man Shakespeare zum ersten Mal lesen. Sie müssen sich daran gewöhnen, bevor Sie in Ihrem natürlichen Tempo lesen können.

Für Entwickler, die zusätzliche Zeit zu stoppen und herauszufinden, eine andere Codierung Stil ist nur reine verschwendete Zeit. Es ist eine Chance für eine Idee, weg zu rutschen, während Sie mit Abstand, Einrückung und Klammerposition festgefahren sind. Am Ende des Tages spielen diese Dinge keine Rolle. Aber lassen Sie mich Ihnen sagen, sie spielen eine große Rolle, wenn sie Entwickler dazu bringen, ihren Fluss zu unterbrechen. Wir brauchten also einen Weg, um sie aus dem Weg zu räumen und die Entwickler das tun zu lassen, was sie am besten können.

Gleichzeitig haben wir uns viel mehr mit JavaScript beschäftigt. Eine neue Sprache, in der Stil generell aus dem Fenster geworfen wurde. Der Code wurde von Beispielwebsites kopiert und eingefügt und zusammengemischt. Als wir lernten, komplexen Code in einer neuen Sprache zu entwickeln, war es sinnvoll, einen Weg zu finden, unser JS ähnlich wie unser PHP aussehen zu lassen. Wir können es später minimieren, aber wir mussten in der Lage sein, schnell zwischen den Sprachen zu wechseln, um unseren Fluss zu halten.

So PHP_CodeSniffer wurde geboren, um das zu tun. Es hilft Entwicklern, nach dem gleichen Codierungsstil zu arbeiten, um Formatierungen und andere Flammenköder vollständig aus dem Weg zu räumen. Es erlaubt Ihnen, Ihre JS wie Ihr PHP in gewissem Umfang zu behandeln. Ich verwende es, um produktspezifische Gerüche wie nicht übersetzte Zeichenfolgen oder Entwickler zu erkennen, die nicht unseren richtigen Klasseneinschlusscode verwenden. Ich verwende es auch für sprachspezifische Gerüche wie zum Beispiel dafür, dass JS-Komma, das den IE tötet, nicht übrig bleibt. Sie können es für alles verwenden, was Sie wollen. Es kommt mit Haufen von Sniffs, die einfach zusammen mit der XML ruleset file zusammengeführt werden können. Sie können auch Ihre eigenen schreiben.Sie können Drittanbieter-Tools integrieren, um es zu einer zentralen Anlaufstelle für statische Code-Analysen zu machen. Du kannst so ernst mit Standards und Code-Gerüchen sein, wie du willst.

PHP_CodeSniffer, wie jedes Entwicklungswerkzeug, sollte für Sie arbeiten. Du arbeitest dafür nicht. Wenn zu viele Fehler erzeugt werden, die Sie nicht interessieren, passen Sie den Standard so an, dass er diejenigen entfernt, die Sie nicht möchten, oder machen Sie die Fehler zu Warnungen. Aber wenn sich meine Geschichte wie etwas anhört, das Sie durchmachen oder in Zukunft durchmachen, lohnt es sich, sich PHP_CodeSniffer genauer anzusehen, um zu sehen, ob es Ihnen helfen kann.

Ich hoffe, dass Sie und andere verstehen, warum Coding-Standards für einige Projekte und Entwickler wirklich wichtig sind. Es geht nicht um das Detail. Es geht darum, den Codierungsstil aus der Liste der Dinge zu entfernen, bei denen Entwickler den Fokus verlieren.

+5

Vielen Dank Greg, dass du deine Geschichte mit uns geteilt hast. Ich war sehr zögerlich, ob ich anfangen sollte, dieses Tool zu benutzen oder nicht. Jetzt werde ich es sicher verwenden. –