I like Coding Standards

Ich hab gestern etwas – ganz lässig und ohne große Erklärungen – bei Linkedin unter dem Titel How To Become A Top WordPress Developer gepostet. Das hat auch genau den Effekt erzielt, den man sich von so einer unmotivierten Aktion erhoffen kann: Nämlich keinen. Allerdings liegt mir die Thematik zu sehr am Herzen, um es dabei zu belassen, sodass ich heute gleich noch einmal mit einem Blogpost nachhake, der Coding Standards in den Mittelpunkt stellt.

Die Codequalität ist mir sehr wichtig. Da bin ich selbst bei meinen persönlichen Projekten immer sehr selbstkritisch.

Bei Aufträgen, die im Team geschrieben werden, finde ich das Thema dann noch viel wichtiger. Die Regeln selbst, wie Code für WordPress-Projekte gestaltet werden sollte, sind ja bereits vorgegeben. Das fängt bei den Codings Standards für PHP an und hört da aber noch lange nicht auf, auch zur Notation von HTMLCSS und JavaScript gibt es ein klares Statement der WordPress-Entwickler.

Solche Regelwerke sind – meiner Meinung nach – auch nicht als etwas anzusehen, das die Kreativität der Entwickler austrocknen soll:

Im günstigsten Fall werden lediglich die Kreationen eingeschränkt, die immer gern als persönlicher Stil eines Programmierers verkauft werden, wenn sonst keine Entschuldigungen mehr greifen.

Coding Standards sorgen zuerst einmal für Leserlichkeit im Code, worüber sich die Kollegen ganz sicher freuen werden. Zudem wird durch einige Vorgaben und durch die Benennung bewährter Methoden die Sicherheit der gesamten Anwendung erhöht, was dann auch die meisten Kunden überzeugen dürfte. Und ein nicht zu unterschätzender Anteil von potenziellen Fehlerquellen wird außerdem so bereits im Vorfeld beseitigt.

Mit HTML und CSS habe ich zwar auch öfter zu tun, aber es gehört nicht unbedingt zu meinem Tagewerk, die Ausgabe von HTML und den dazu gehörenden Stylesheets valide und performant zu halten. Das überlasse ich gern fähigen Webdesignern. Damit die ganze Geschichte aber nicht nach hinten losgeht, weil die Standards eventuell zu einer Auslegungsfrage verkommen und man am Ende mehr Zeit mit Grundsatzdiskussionen als mit dem Schreiben von Code verbringt, kommen entsprechende Tools zum Einsatz.

Für JavaScript setze ich seit einiger Zeit auf JSLint, ein Projekt welches ich jedem Entwickler nur empfehlen kann, wenn es nicht schon bekannt ist. Für die PHP-Scripten setze ich auf den PHP_CodeSniffer. Kürzlich erzählte mir ein Teamkollege von seinen Schwierigkeiten den Sniffer mit den WordPress Coding Standards aufzusetzen. Das ist eigentlich – zumindest auf einem Ubuntu-artigen System – recht einfach zu bewerkstelligen:


# Install PHP_CodeSniffer
sudo apt-get install php-codesniffer
# Install the WordPress Coding Standards
sudo git clone git://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git \
$(pear config-get php_dir)/PHP/CodeSniffer/Standards/WordPress
# Now your can check your files like this
phpcs –standard=WordPress your-file.php
# or you could set the WordPress Coding Standards as your default
sudo phpcs –config-set default_standard WordPress
# and use the CodeSniffer like so
phpcs your-file.php

view raw

gistfile1.sh

hosted with ❤ by GitHub

Zum Schluss noch ein Bookmark zu einer thematisch passenden Sache, die ich mir demnächst noch genauer ansehen möchte und die eventuell auch noch ein paar neue Impulse bringt:  PHPMD – PHP Mess Detector

Was sagt ihr dazu? Setzt ihr die selben Tools ein oder benutzt ihr andere? Oder sind Coding Standards vielleicht gar kein Thema bei euch?

8 Gedanken zu „I like Coding Standards“

    1. Ich seh‘ das etwas anders, aber vielleicht möchtest Du das gern etwas detaillierter ausführen, @audible?

      BTW Wenn eine Website zwar angegeben wurde, aber zum Zeitpunkt der Veröffentlichung des Kommentars einen 404 zurück gibt, nehme ich sie in der Regel ‚raus (so wie in diesem Fall).

    1. Ich seh‘ das etwas anders, aber vielleicht möchtest Du das gern etwas detaillierter ausführen, @audible?

      BTW Wenn eine Website zwar angegeben wurde, aber zum Zeitpunkt der Veröffentlichung des Kommentars einen 404 zurück gibt, nehme ich sie in der Regel ‚raus (so wie in diesem Fall).

  1. LinkedIn, kein Wunder dass Du da keine Antwort erhalten hast. Die LinkedIn-Artikel sind größtenteils Spam. Da hat wohl schlicht und einfach niemand mit einem „echten“ Artikel gerechnet. 😉

  2. LinkedIn, kein Wunder dass Du da keine Antwort erhalten hast. Die LinkedIn-Artikel sind größtenteils Spam. Da hat wohl schlicht und einfach niemand mit einem „echten“ Artikel gerechnet. 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert