 Dann haben wir es geschafft. Herzlich willkommen zu einer der ersten Sessions. Wer bin ich? Ich bin Thorsten Frommen. Ich bin Web-Entwickler und habe mit WordPress seit 2006 zu tun. Arbeiter als Senior-Entwickler bei HumanMate. Und ich bin ein Community-Mensch. Hab die Community ziemlich spät kennengelernt, erst 2013 im World Camp Hamburg und seitdem fast alle Camps in Deutschland und ein bisschen Umland irgendwo mitgemacht. Und heute geht es um Coding-Standards. Erst mal, was sind Coding-Standards? Im Prinzip ist es einfach nur eine Ansammlung von Regeln und Richtlinien, die sich auf das Programmieren, auf das Code schreiben beziehen. Im Prinzip ist es ein Standard, wenn es von vielen Leuten genutzt wird, diese Regeln. Das heißt, wenn wir hier zur Terminologie kommen, wir haben also diese Coding-Standards. Das heißt wirklich ein Regelsatz, den ganz viele Leute benutzen, der auch wirklich teilweise Leuten vorgegeben wird, zu benutzen. Jeder kann sich aber selbst einfach Coding-Conventions erschaffen. Das heißt, ich entscheide für mich, für ein privates Projekt, das sind meine Regeln, nach denen ich gerne Code schreiben möchte, formatieren möchte und so weiter. Diese Coding-Conventions werden halt ein Standard, wenn ich eine Firma habe, wenn ich irgendeine Gruppe anführe oder da zu sagen habe und ganz viele Leute sagen, diese Konventionen sind cool, dann machen wir jetzt alle so. Und wir sagen auch 9 Leuten, die bei uns mitmachen, die sollen das so machen. Das ist ein Standard. Diese Regeln können halt unterschiedlicher Natur sein. Zum einen ist es Code-Style. Das heißt einfach nur das Aussehen vom Code, die Formatierung. Das heißt, wo habe ich White Space, wo habe ich New Line, wo setze ich irgendwie Line Breaks und weiß ich nicht was. Es kann sich um Best Practices handeln. Das heißt, es geht darum, ein Problem zu lösen. Es gibt mehrere Möglichkeiten und manche Leute haben halt was ausprobiert und gesagt, das ist die beste oder eine der besten Möglichkeiten. Das heißt, es wird vorgeschrieben, wie ein Problem zu lösen ist oder wie bestimmte Code Snippets zu schreiben sind, was man sich von der Sprache als Zunutze macht. Es kann um Naming-Conventions gehen. Das heißt zum Beispiel, wie benenne ich meine Variablen? Wie benenne ich Funktionen, Methoden? Wie benenne ich meine Dateien oder Ordnerstruktur und ähnliches? Es kann um die Kommentierung oder Dokumentation von Code gehen. Das heißt, im Code selber habe ich Inline-Dokumentation, brauche ich es nicht, weil meine Variablen, die Methodennamen und so weiter halt selbst erklären sind und viel, viel mehr. Wer definiert jetzt das Code Standard? Ich habe ja eben als Beispiel genannt, wenn ich eine Firma habe und sage, ich mache das, dann bin ich derjenige. Im Prinzip kann es halt der Erfinder oder die Erfinder einer Programmiersprache sein. Bei Go zum Beispiel. Da kam direkt die Konvention mit der Programmiersprache. Es kann eine Firma sein, zum Beispiel SEND, für dieses SEND Framework. Da wurde vorgegeben, das und das macht Sinn. Es wurde später von den Leuten, die dieses Framework nutzen, natürlich auch adoptiert. Aber erst mal gab es diese Vorgabe. Es kann ein Community-Ergebnis oder ein Effort, was das deutsche Name, ein Bestreben einer Community sein, wie die WordPress Coding Standards. Letzten Endes ist es aber einfach, ein Standard ist ein Standard, wenn diese Regeln von einer ganz großen Menge in irgendeinem Bereich benutzt werden. Wie gesagt, es kann eine Programmiersprache sein, es kann eine Library in irgendwas sein und irgendwie ein Großteil von einer Gruppe Menschen, die folgen diesen Regeln, dann ist es ein Standard. Warum interessiert uns das? Also erst mal, das naheliegendste ist, wenn alle Leute den gleichen Regeln folgen, dann ist es einfacher zu verstehen. Es ist einfacher zu lesen. Der Code ist einheitlich geschrieben, nicht nur der Code in einer Datei, sondern der ganze Aufbau von einem Projekt, wenn das eben in den Regeln enthalten ist, was natürlich dazu führt, dass die Wartung des Codes viel einfacher zu erfolgen kann oder eigentlich erfolgt. Man weiß, wie Sachen aufgebaut sind. Das heißt, man verschwettet keine Zeit mit dem Verstehen des ganzen Projekts mit der Struktur, sondern fixt einfach ein Bug oder soll irgendwo ein neues Feature einbauen, weil man weiß, wie und wo man es zu tun hat. Es gibt Security, also Sicherheitsrelevante Best Practices oder sonstige Coding Standards, das heißt, wenn man denen folgt, ist der eigene Code sicher, beziehungsweise sicherer. Und alles zusammengenommen fügt das Verfolgen und Einhalten und selbst erschaffen von Coding Standards halt zu der Qualitätssteigerung bei. Es gibt im Deutschen diesen Spruch, Regeln sind da, um gebrochen zu werden. Ich finde, das ist nicht ganz richtig. Man kann es so verstehen, dass Leute nur Regeln erschaffen, damit andere sie brechen. Ich denke, es ist eher so zu verstehen, dass Regeln da sind, weil es ein Grund dafür gibt, aber es gibt irgendwo, oder man sollte auch Freirom lassen, um diese Regeln zu brechen oder vielleicht umzuschreiben. Ein ganz kurzes, lustiges Beispiel. Ich wohne in der Wohnung in einem Haus, in einem Häuserkomplex und wir haben unter unseren Häusern eine Tiefgarage. Irgendwann kam der Hausmeister zu mir und hat gesagt, du hast da bei dir auf dem Parkplatz was stehen, das geht so nicht. Pack das mal weg, sonst muss ich dich verwahren. Ich dachte, wovon redet der denn? Ich gehe mit ihm runter, guck auf den Parkplatz, guck ihn an. Es ist ein Ernst, was ist denn der Grund? Ja, es steht in der Hausordnung, es darf nur ein Fahrzeug auf dem Parkplatz stehen, weil alles andere könnte Feuer fangen. Und das stand halt drauf. Es gibt diese Regel, es ist ein bisschen fragwürdig, wann und wie man sie einzuhalten hat. WordPress Coding Standards. Gibt es WordPress Coding Standards? Ja, habe ich schon vorweggenommen, die gibt es. Die leben auf make.wordpress.org. Das ist eine, im Prinzip, eine Sammlung von Seiten, die erklärt, was es für Standards gibt, warum es die gibt, wie man sie einzuhalten hat und Ähnliches. Okay, was gibt es denn also? WordPress ist grundsätzlich PHP. Auch durch Gutenberg, Calypso und was auch immer mit JavaScripts. Die Basis ist immer noch PHP. Das heißt, wir haben PHP-spezifische Standards. Natürlich haben wir aber auch JavaScript. Wir haben HTML, weil es eben nur mal eine Website produziert. Wir haben CSS, weil wir unsere Websites auch selber steilen möchten. Zusätzlich gibt es noch Accessibility, also zugänglichkeitsbetreffende Richtlinien. Die ersten vier Sachen sind mehr oder weniger Programmiersprache oder Technologie spezifisch und Accessibility wuselt sich überall durch. Das hat überall Regeln, die man beachten kann oder beachten sollte. Was gibt es denn dafür Regeln? Bei PHP gibt es zum Beispiel, wir benutzen Tabs zum Einrücken und keine Spaces. Das ist also formatierungsspezifisch. Wir haben in PHP gibt es elseif als ein Keyword. Bei if, bla, bla, bla, elseif, bla, bla, bla, meinetwegen noch ein else. Oder man kann schreiben elseif und es ist einfach vorgegeben, damit der Code einheitlich ist. Wir schreiben immer elseif als ein Keyword. Das ist also ein bisschen Best Practice oder einfach Vorgabe. Es ist kein Unterschied letzten Endes. Es ist einfach so festgelegt. Wir haben in PHP nutzen wir immer noch Defines und die schreiben wir komplett im uppercase und wenn wir irgendwo ein Bindezeichen brauchen, ein Delimiter oder Verbindungszeichen, ist es ein Anderscore. Wir haben keine Leerzeichen am Ende der Zeile, was natürlich auch heißt, dass wir keine Leerzeichen in einer leeren Zeile haben. Es wird nicht eingerückt. Wir benutzen für Strings einfache Anführungszeichen und wir haben überall Leerzeichen, wo es eigentlich nur geht. Das macht die WordPress Coding Standards halt ziemlich bekannt. Das ist halt fast nirgendwo so. Im HTML haben wir alles, was wir in Text haben, es wird kleingeschrieben. Wir haben immer die Anführungszeichen. Wir haben die Anführungszeichen. Wir schreiben immer die Werte von Attributen in Anführungszeichen, auch wenn man es nicht machen müsste. Zum Beispiel, wenn irgendwo eine Zahl steht oder nur ein String wird es auch von den Browsern so interpretiert, als wäre es mit Anführungszeichen geschrieben. Vorgabe ist, wir benutzen immer Anführungszeichen. Wenn wir Self-Closing-Tags haben, haben wir immer vor dem Abschließenden CSS Coding Standards. Wir haben auch hier die doppelten Anführungszeichen, die wir verwenden. Wenn wir sowas haben wie Input, Type, irgendwas, dann genauso wie wir es halt immer HTML schreiben, nutzen wir hier Type gleich, was auch immer, Button. Unsere Properties werden direkt von dem Doppelpunkt gefolgt. Dann haben wir ein Leerzeichen und dann kommt der Wert oder die Definition für dieses Element. Und Media Queries werden halt so formatiert. Das heißt, ich weiß nicht, ob das Leerzeichen sein muss, es steht nicht in der Regel, aber es ist halt eben eingerückt, was ist ein Block und alles, was man reinschreibt, wird eingerückt. Accessibility. Für Ajax Request oder eben die Response davon nutzt, wenn möglich, AliSpeak, das ist JavaScript in dem Fall. Das heißt, für Screenreader und ähnliches wird da dann eben die Zugänglichkeit gefördert. Für Bilder nutzen wir den Namen im Altattribut. Das ist HTML spezifisch. Dann haben wir noch CSS. Wenn wir irgendwo Links haben, wo es nicht eindeutig zu erkennen ist, dass das ein Link ist, zum Beispiel eindeutig zu erkennen, ist es in einem Menü. Da sind wahrscheinlich alle Elemente Links, die kann man klicken, um irgendwo hinzukommen. Aber im Fleece Text sollten Links unterstrichen werden. Okay, wie fängt man denn jetzt an, wenn man das selbst sich zu Herzen nehmen möchte und befolgen möchte? Ein sehr einfacher Einstieg ist Editor-Config. Wer hier kennt das Projekt Editor-Config oder die Datei, die so heißt? Einer, zwei, drei, vier, okay, fünf, ist vom Raum hier vielleicht ein Zehntel oder so. Editor-Config ist wie gesagt eine Datei. Es ist ein Dot-File, also ein Konfigurationsdatei, die im Prinzip Regeln beinhaltet, wie Code zu formatieren oder zu verwalten ist. Diese Datei selber wird von ganz vielen Editoren oder IDIs unterstützt. Manche machen es direkt von Hause aus. Für manche gibt es einen Plug-in, das man installieren muss, damit es eben verstanden und befolgt wird. Diese Eigenschaften oder Properties, die man nutzen kann, sind die hier. Zum Beispiel kann man sagen, das ist eine Datei. End of line soll es Linux-Style sein oder Windows-Style und UTF-8 oder was auch immer. Zusätzlich gibt es noch eine. Das ist die maximale Zeilenlänge, die nicht von allen unterstützt wird. Aber ich glaube, inzwischen auch schon ist ja nicht so schwer. Aber wurde halt nachträglich hinzugefügt, nachdem dieser erste Regelsatz definiert wurde. Das ist eine Beispieldatei. Es funktioniert so, dass man sagt, das hier ist im Prinzip entweder ein Dateiname Pattern für einen Dateinamen. In dem Fall heißt es alles. Was auch immer du für eine Datei hast, das ist die Definition. Also UTF-8, Linux-Style-Ending. Wir möchten ganz am Ende einen Zeilenumbruch haben und so weiter. Weiter unten kann man Sachen entweder neu definieren. Zum Beispiel in den Styles haben wir oben nicht definiert. Dann ist es Aufgabe des Editors oder der IDE. Was ist denn mein Standard? Man kann auch den Wert, der vorher definiert wurde, rückgängig machen oder eben neu setzen. Das heißt, wir haben in der Regel immer ein Tab, das wir nutzen. Aber für Yaml-Dateien, weil es nun mal so vorgegeben ist, fast alle Paarser verstehen es nur, wenn es mit Spaces eingerückt ist, müssen wir Spaces nutzen. Dann wollen wir in der Regel das letzte, also alle nachfolgenden Widespaces löschen, für Markdown braucht man sie aber. Wenn man zum Beispiel einen einfachen Zeilenumbruch macht, je nachdem, was man für Markdown ein Paarser hat, braucht man zwei Leerzeichen am Ende, damit eben die nächste Zeile nur einmal umgerückt wird. Die nächste Sache, wenn man Git nutzt für die Versionierung des Codes, kann man sich die Datei Git Attributes zu nutzen machen. Eigentlich ist es für was anderes gedacht, das ist auch eine Konfigurationsdatei, eigentlich für Git selber, aber man kann sehr wenige Sachen auch auf die Formatierung bezogen nutzen. Das heißt, wir haben auch wieder Fahrtnamen oder Pattern und machen Definitionen dafür. Das ist ein einfaches Beispiel. Wir haben also alles, was wir finden, sagen wir erstmal, das ist eine Textdatei. Ich weiß nicht genau, was damit zusammenhängt, aber das sind mehrere Sachen, die dann eben mit diesen Dateien gemacht werden. Und speziell sagen wir, das Line-Ending soll eben Linung-Style sein. Wenn wir aber ein JPEG haben oder eine PNG-Datei, dann ist das eine Binaire-Datei. Versuch dann nicht plaintext rauszumachen, verstehst du nicht, das ist eine Binaire-Datei. Und dann gibt es eben noch ganz viele andere Sachen, die jetzt tatsächlich dann auf Git bezogen sind. Zum Beispiel, wenn man das nutzt, dann sollte man diese Datei selber vom Export ausschließen. Das heißt, wenn sich Leute einfach die Zip-Datei von Git-Hubschnappen oder sowas, dann wollen sie nichts entwickeln. Dann wollen sie einfach nur deinen Plug in oder was auch immer nutzen, dann brauchen sie das nicht. Und da kann man noch ganz viel weiteres hinzufügen. Okay, ein bisschen nerdy passend zum Titel. Was ist das? Ihr habt bestimmt alle direkt erkannt an der großen Schnüffelnase. Das ist der PHP Coach-Nüffler. PHP Coach-Nüffler ist ein Tool. Man füttert Regeln in dieses Tool und das Tool läuft über ganz viele Dateien rüber und sagt, ob die Regeln eingehalten werden und wenn nicht, wo nicht und warum nicht. Tatsächlich ist es nicht nur für PHP-Dateien, sondern es versteht auch JavaScript und CSS. In WordPress nutzen wir es aber nicht so und ich persönlich finde auch, dass das Sinn macht, denn es ist für PHP gedacht ursprünglich und es gibt für CSS, SAS, für JavaScript deutlich bessere und mächtigere Tools. Das heißt, für WordPress ist der Coach-Nüffler tatsächlich das Haupttool für tatsächlich Code-Convention oder Coding-Standard-Kontrolle. Die Standards sind im Prinzip, wie halt die Definition, ein Standards, eine Sammlung von einzelnen Regeln und wenn man das Tool sich irgendwie beschafft, einfach runterlädt oder über Composer oder wie auch immer man es machen möchte, kommen ein paar Regeln mit. Zum Beispiel diese. Per, das heißt teilweise PHP-spezifische Sachen, PSR2, das ist ein eigener Standard, der dann da direkt schon wieder Regeln beinhaltet. Send, das ist eben diese Send Framework 2 Standard und viele mehr. Natürlich gibt es eben auch WordPress, nicht natürlich, es gibt auch WordPress Coding Standards, weil wir PHP Codes nutzen, macht es eben Sinn, dass man diese Standards irgendwo bündelt. Es gibt einmal WordPress selber, das ist der Name von diesem Standard, der beinhaltet alles, was es spezifisch gibt. Das ist nicht der Standard, den WordPress selber verwendet. Es gibt dann halt noch feinere Standards, die alle in diesem Gott Standard einfach genutzt werden. Das heißt, WordPress Core beinhaltet nur die Regeln, die, wenn man tatsächlich an WordPress der Software selber mitentwickelt, die dann befolgt werden sollten. Zusätzlich gibt es noch VIP-spezifische Sachen. Das ist zum Beispiel, wo auf sehr traffic-lastige Seiten berücksichtigt wird, was man da anders machen sollte, bestimmte Funktionen zum Beispiel nicht nutzen, weil sie kein Cash nutzen oder ähnliche Sachen. Es gibt für Dokumentation spezifische Sachen. Es ist gerade in der Mache, dass man reine ästhetischen Sachen, sprich Formatierung von Best Practices und eben Sachen, die potenzielle Fehler vorbeugen können, dass man diese Sachen trennt. Das ist aber schwer, weil es eben diesen Standard schon lange so gibt. Es muss entschieden werden, was soll wo rein. Nach und nach werden auch Coding-Regeln von einem Standard in den anderen beschoben, dass man eben sagt, ja, bisher konnte man diese Regeln nicht wirklich folgen, weil wir haben halt diese Regel nicht befolgt in WordPress Core. Das heißt, wenn wir einfach sagen, die ist aber jetzt Standards, dann würde PRPCS sagen, so und so viele Tausend Fehler, was natürlich nicht sinnvoll ist. Man muss dafür sorgen, dass der Code Compliance den Regeln halt entspricht. Dann kann man diese Regel tatsächlich als Vorgabe machen. Und es gibt viele mehr. Es gibt aber auch noch weitere PHP-Codes in den Verstandards, die jetzt nicht mit Codes in den Verselber kommen und die auch nicht die WordPress-Regeln sind, die für uns aber sinnvoll sind. Zum Beispiel PHP Compatibility. Ich kann sagen, mein Plug-in, mein Theme soll ab PHP Version so und so bis unendlich oder nur für PHP 7 und 7.1 nicht, weil, keine Ahnung, soll damit laufen. Und dieser Standard checkt einfach alle Sachen, die sich von PHP, ich weiß nicht wo, 5.2.4, 5.3 oder sowas, bis eben wo man möchte geändert haben und ob das eben diesen Anforderungen entspricht. Im Prinzip stellt das sicher, dass PHP der Pasa nicht irgendwann sagt, das verstehe ich aber nicht, das ist was falsch. Es gibt Security-spezifische Coding-Standards. Nicht WordPress-spezifisch, aber eben all das, was wir auch im WordPress-Kontext nutzen. Es gibt einen Neutron-Standard von Automatic. Das ist für PHP 7 und weiter, also eben State-of-the-art-Sachen. WordPress ist ja ein bisschen hinterher. Deswegen hat sowas dann eben irgendwo anders ein Zuhause gefunden oder finden müssen. Und es gibt natürlich viel, viel mehr. Lassen wir uns doch mal so eine Datei anschauen. PHP.CS ist ein Library, ein Binary. Das kann ich komplett in der Kommandezeile ausführen. Ist aber müßig, wenn ich das sehr umfassend konfiguriere. Deswegen gibt es Konfigurationsdateien, wo ich einmal reinschreibe, so sieht es aus. Dann muss ich nur die Datei ausführen und diese Konfiguration, diese Definition, wie möchte ich dich benutzen, wird gelesen und befolgt. Das ist eine XML-Datei. Ich habe hier einfach mal einen Namen gewählt. Braucht man nicht. Aber dann hat man eben, weil wir mehrere Codeblöcke haben, dann weiß man noch so ein bisschen, was der Unterschied ist. Das ist einfach ein ganz einfacher Standard. Als erstes kann man sagen, da, wo man die Datei ausführt, auf was für Dateien oder Ordnerpfade man denn überhaupt laufen möchte. Das macht zum Beispiel keinen Sinn, JavaScript-Dateien zu testen oder alle Dateien, die man irgendwo hat. Man kann tatsächlich nur PRP-Dateien nutzen möchte. Oder wenn man nur in einem Ordner PRP-Dateien hat. In dem Fall habe ich jetzt mal hier ein Beispiel Plugin mitgenommen. Ich habe hier Source, da ist mein PRP-Code. Ich habe eine Index PRP, das ist meine Main Plugin-Datei. Und ich habe eine Uninstall, und die drei Patterns möchte ich eben nutzen. Zusätzlich sage ich aber, ich möchte keinen Node-Modules. Es ist jetzt ein komisches Beispiel. Eigentlich hat das nichts in Source zu suchen, aber man kann eben auch Sachen wieder rückgängig machen. Man kann irgendwo Patterns getroffen werden. Diese Dateien, die diese Pattern entsprechen, also sprich alles, was irgendwo in Node-Modules ist, wird einfach nicht getestet. Ich kann auch sagen, welche Dateiendungen ich nur testen möchte. Zum einen ist es sinnvoll, um Sachen zu spezialisieren. Ich möchte nur PRP-Dateien testen. Oder aber auch kann ich das rückgängig machen, wenn es irgendwo anders gemacht wurde. Weil ich zum Beispiel auch PRP-Template-Dateien habe mit einer anderen Dateiendung. Ich möchte die auch testen lassen. Dann gibt es noch Flex. P und S sind zwei Flex. Wie man von der Kommande-Zeil ist, kann man die halt ineinander schreiben. P steht dafür, dass man den Progress sieht, während das Tool läuft. Und S ist für alle Ausgaben, die man irgendwo sieht, wird der Sniff. Das ist quasi die Regel selber, der Name von dieser Regel. Zum Beispiel PRP, was weiß ich, Naming irgendwas und dann Invalid, Capitalization oder irgendwie sowas. Das wird dann überall auftauchen. Dass man direkt weiß, nicht nur die Textbeschreibung hier, das und das ist aber falsch. Man sieht direkt den Sniff, kann danach suchen. Vielleicht irgendwo auch ein Bug melden. Mein Code ist aber eigentlich richtig. Das wurde aber als falsch erkannt. Schau mal bitte nach, das ist dieser Sniff, um den es geht. Dann nutzen wir einen Regelsatz, beziehungsweise einen Standard. Das ist eben dieser PRP-Competibility. Und ich möchte in meinem Plug-in nur PRP 7 unterstützen und alles was kommt. Das heißt, selbst wenn ich da jetzt PRP 5.0 irgendwas in kompatibelem Code drin habe, das ist von mir gewollt. Das sage ich meinem Tool und der sagt dann auch einfach nur, ob das PRP 7.0, 7.1, 7.2 kompatibel ist. Und dann nutze ich diesen Gott-Standard-Wordpress. Das ist mein Regelsatz. Man kann aber natürlich auch nicht nur komplette Standards nutzen, sondern das ist jetzt wiederum die Datei und wir haben eben das wieder andere Sachen. Zum Beispiel einen speziellen Sniff nutzen. Also ich sage, ich möchte nicht den Generic-Standard, ich möchte nicht diese PRP-Kategorie, ich möchte einfach nur diesen Sündersniff nutzen. Oder man kann Sachen nutzen und sie aber entweder beschneiden, dass man sagt, ich nehme WordPress alles was es gibt, weil es ist einfacher, als alles einzeln zu benennen. Zum Beispiel auch wenn Sachen irgendwann mal neu eingeführt werden und vorher gesplittet sind und ich sage, ich möchte WordPress, kriege ich alles. Ich möchte aber nicht die VIP-Spezifischen Sachen, weil ich habe immer nur ganz kleine Seiten und ich weiß was ich mache und keine Ahnung, so kann man das anpassen. Man kann aber auch Eigenschaften von einem Sniff selber anpassen, dass man zum Beispiel sagt, die Definition von WordPress Hooks oder Hooknames ist, man hat alphanumerische Zeichen und man hat ein Anderscore. Ich möchte aber ein Prefix haben, dann einen Punkt und dann den Hookname und meinem Prefix könnte ein Anderscore drin vorkommen. Das heißt, ich kann hier sagen, ich möchte als zusätzlicher Delimiter auch noch den Punkt zulassen. Ich finde es ziemlich sinnvoll, wenn man einfach nur schnell mal die Coding-Standards überprüfen lassen möchte, sich nicht zu viel Ausgabe erschafft und zu viel Ausgabe checken muss. Das heißt, standardmäßig lass ich einfach nur das Tool laufen und sehe dann eine Zusammenfassung im Output in meiner Konsole. Ich kann mir aber in einer anderen Datei erschaffen. Was ich hier mache ist, das ist hier ein neuer Standard mit Reports. Ich nehme einfach diesen Regelsatz von Eben. Den nehme ich als Standard und der wiederum hat ja andere Standards importiert, das kann ich machen und sage dann aber noch, ich hätte gerne den vollen Report, ReportFull, ReportSource und ReportSummary sind 3 vordefinierte Reports von PRPCS, es gibt noch mehr, die finde ich sinnvoll und ich möchte die 3 haben in jeweils einer eigenen Textdatei und ich möchte das caching. Das heißt, es wird einmal irgendwo in eine Datei oder was weiß ich geschrieben, das ist der Zeitpunkt, wo das erzeugt wurde und wenn ich diesen Standard nochmal nutze, prüft PRPCS irgendwie, ob sich Dateien geändert haben, wenn nicht, wird mir direkt das gecached Ergebnis von vorher präsentiert und falls ja, dann wird nochmal neu gelaufen. Wie benutzt man den Kotzeniffern nun? Es ist eine Kommandozeilen-Datei, das heißt, ich füge sie in eine Kommandozeile aus. Ziemlich cool ist aber, dass ich nicht nur gesagt bekommen kann, das und das ist falsch, sondern ganz viele Sniffs können automatisch gefixt, ganz viele Violations-Rolligungen, können automatisch gesnift werden, gefixt werden. So einfache Sachen wie ich hätte gerne ein Space zwischen all meinen Argumenten und weiß ich nicht was, wenn halt kein Star ist oder wenn mehrere da sind, weiß das Tool genau, was ich möchte. Ich möchte einen Space vor oder nach der öffneten Klammer, nach einem Kommen und ich möchte auch ein Space. Dann kann das automatisch für mich gefixt werden. Es geht nicht bei allen Sachen, weil bei vielen Sachen weiß ich nur, das ist falsch, aber es gibt mehrere Möglichkeiten, es richtig zu machen. Das ist ein sehr schlechtes Beispiel von einer WordPress Core Funktion. Die habe ich umformatiert, die sieht nicht so aus. Man sieht ja schnell, dass hier ein paar Sachen nicht so sind, wie wir sie kennen, wie sie aussehen sollten. Wenn ich da jetzt den Kotzeniffern machen, das ist also wirklich, ich habe die Entwickler-Version von WordPress genommen und habe es einfach mal laufen lassen, das ist die Ausgabe, sind also viele Sachen zu fixen. Wenn ich jetzt diesen Kot Beautifier laufen lasse, sehe ich, wow 17 Sachen wurden automatisch für mich erledigt, 4 aber nicht. Das ist die Datei, wie sie danach aussieht. Was falsch ist, was angemengelt wird, aber wo man nicht weiß, wie es denn richtig ist, ist zum Beispiel, dass wir hier eine d-Case nutzen und kein und es wäre eine Möglichkeit zu sagen, überall, wo ich nach dem ersten Buchstaben einen Großbuch stammen sehe, mache ich einen und schreibe den klein. Ist aber nicht unbedingt sinnvoll. Deswegen hat man es nicht gemacht. Zum Beispiel können Leute auch Post ID, das D auch noch groß schreiben, weil ID ist eine Abkürzung usw., denn hätte man Post unterstrich D ist auch nicht richtig. Eine andere Sache ist, dass es diese Variable ist, man kann keine Werte setzen. Das heißt, was wir hier machen müssen ist, wir setzen diesen Wert Post, gleich getPost, was auch immer, außer halb unseres ifs und überprüfen einfach nur if not post. Das gleiche hier unten und irgendwo war noch mal was, also noch mal hier Post ID, das war falsch. Das heißt, wenn ich das jetzt manuell fixe, habe ich ganz wenig zu tun. Ich benenne diese Variable tatsächlich so um, das ist so halb meines ifs, von User ID und jetzt ist alles richtig. So entspricht der Code den Code Standards. Das ist aber natürlich nur eine Möglichkeit, weil ich kann überall Leerzeilen einfügen, das wird mir nicht gesagt, du darfst keine Leerzeilen haben. Das ist Code, der ist kompatibel zu den Standards, das ist aber nicht der Code, so wie er auszusehen hat. Das ist wichtig. Wenn ich jetzt coach eine Vernutze, kann es ja aber sein, dass ich irgendwo in meinem Code Sachen komme, wo ich nicht wirklich weiß, wie ich damit umzugehen habe, weil entweder sind sie falsch oder auch nicht oder es gibt eine Ausnahme, aber ich möchte das nur speziell dafür ändern. Es gibt die Möglichkeit, dass man über Kommentare, das Tool einfach informiert, was es zu tun hat. Ignore heißt einfach die Zeile, in der das, in der der Kommentar quasi am Ende steht oder wenn es in einer eigenen Zeile steht, die nächste Zeile, ignoriere die einfach bitte mal. Egal was du findest, ich will es nicht wissen. Ich kann das ganze Tool disable, dann ist es bis zum Ende der Datei oder bis es wieder enable findet. Das heißt also auch, alles, was das Tool eigentlich machen würde, macht es nicht. Und ich kann direkt eine ganze Datei für diese Datei einfach sagen, will ich nicht mehr, dass du hier irgendwas machst. Zusätzlich kann man bei manchen dieser Kommentare aber auch noch Sniffs angeben, dass man nicht einfach sagt, ignoriere mal die nächste Zeile, sondern ignoriere in der nächsten Zeile nur alles, was in diesem Standard falsch wäre oder ab hier disable diese Kategorie von diesem Standard zum Beispiel. ESLint ist im Prinzip für JavaScript das, was Coachingover für PHP ist. Ich muss euch jetzt ein bisschen beeilen, weil wir halt Verzögerung hatten. Es ist eine ziemlich einfach und ziemlich hochkonfigurierbare ja Validierungsmaschine für JavaScript und auch für JSX mit dem ESLint Tool selber kommen diese Kategorien von Regeln. Und ich kann mich entscheiden, was ich nutzen möchte. Es gibt zusätzlich auch noch ein Recommended Scheme, da werden aus verschiedenen Kategorien verschiedene Regen automatisch gesetzt, weil ganz viele Leute, nicht Wordpress Leute, sondern aus dem JavaScript Bereich, aus dem JavaScript Universum, weil die sagen, das macht Sinn. Konfiguration sieht so aus. Ich habe irgendwelche Informationen für das Tool selber, zum Beispiel ich nutze der Textcode, ich habe hier Module, die ich schreibe und so weiter. Es gibt Plugins, die können das Tool erweitern, im Sinne von neue Regeln hinzufügen oder aber auch die Verarbeitung des Outputs, neue Reports und was auch immer machen. Und dann habe ich meine Regeln selber. EQ, EQ, EQ ist eine Regel von ESLint, die sagt einfach nur quasi strict comparison dreifaches Gleichheitszeichen soll genutzt werden. Und Import ist ein Plugin, das fügt neue Regeln hinzu und ich nutze einfach hier. Wie man das benutzt, ist ähnlich wie ppcs, es ist ein CLI und es gibt auch dieses Auto Fixing, hier ist es keine eigene Datei, kein Eigensbinary, sondern es gibt eben dieses Flack, dort fix, fix alles was du kannst. Genauso wie bei ppcs, ich mache es ein bisschen schneller, kann man Sachen disablen. Namen sind ein bisschen anders, aber im Prinzip ist es ähnlich, man hat hier eben tatsächlich disable line, das ist also wenn es ein Moment ist. Und es gibt disable next line und man kann eben hier auch sagen welche Regeln irgendwo ignoriert werden sollen. Es gibt für WordPress spezifisch auch eine Config, das heißt die kann man einfach nutzen und immer noch in seinem Regelsatz Sachen hinzufügen oder und undu rückgängig machen. Das wird einfach sagt, ja gut WordPress dacht halt eben diese Regel so und so zu sein, ich will sie gar nicht. Dann sagt man hier zum Beispiel irgendeine Kul, das heißt, interessiert mich nicht. Eins wäre, sagt mir das ist eine Warning, zwei ist eben ein Fehler. Für JavaScript gibt es auch noch Pretier. Pretier beschreibt sich selber als Opinionated Code Formatter. Das heißt letzten Endes, dass es nicht so konfigurierbar ist wie ESLint und es gibt einfach viel mehr wie zu WordPress passend Decisions not options, es ist einfach viel mehr vorgegeben wie Code auszusehen hat. Pretier kümmert sich nur um die Formatierung vom Code und man kann Pretier mit ESLint nutzen und man sagt bei ESLint einfach nur, ich möchte best Practices hier und Pretier soll einfach Pretier kann alles was es an Regeln gibt Autopixen, weil es Formatierung ist. Ich möchte einfach nur ESLint für meine Best Practices nutzen und ähnliche Sachen und dann einfach Pretier drüber laufen lassen und alles ist schön. Problem ist, es passt nicht zu den WordPress Coding Standards. Es gibt dann Issus seit einem halben Jahr und die sind dann nicht wirklich, will ich das irgendwie anzupassen. Aber ja, Pretier arbeitet nicht nur für JavaScript, da ist es aber am bekanntesten glaube ich, sondern auch für CSS und mehr, eine ganze Menge mehr. Unter anderem arbeiten die auch an PHP. Ist die Frage was da halt irgendwann mit passiert. Pretier wird aktuell nicht genutzt, weil es eben nicht so mit WordPress wirklich, also das Tool so wie es existiert ist nicht mit WordPress zu nutzen weil eben ein paar Regeln nicht so umzusetzen sind, also ein paar WordPress Regeln kann man Pretier nicht beibringen. Automatic hat Pretier geforgt, die haben es einfach dann quasi kopiert und angepasst um Calypso glaube ich damit testen zu lassen, was auch nicht Sinn der Sache ist. Falls ihr Interesse daran habt, haut mal diese drei Leute auf Twitter an, das sind einfach nur von denen ich weiß, die damit rum experimentieren. Letzte Sache, nochmal ein bisschen den Bogen zurück zu, warum ist das denn alles wichtig. Ich hoffe, ihr habt ein bisschen verstanden, warum Coding Standards und warum die Existenz von Coding Standards und das Befolgen von Coding Standards sinnvoll ist für euch, aber es ist nicht nur jeweils ihr als Autor, den das interessiert. Es gibt ein neues Projekt Tide, das ist für euch einfach so zu sehen, wenn ihr ein Plugin oder ein Theme in den offiziellen Directories habt, dann kümmert sich jetzt auch jemand anderes darum, was ihr mit eurem Code macht, ob ihr Coding Standards verfolgt. Aktuell wird nur die PHP-Kompatibilität getestet. Es passiert auch nichts, es wird einfach nur getestet und die Aussage gemacht über hör mal, das Plugin funktioniert nicht mit 7.2, weil so und so und so. In Zukunft ist es aber bestimmt denkbar und wird auch so sein, dass Regeln die euren Konfigurationsdateien entsprechen, wenn ihr welche habt oder dann halt bestimmte, wahrscheinlich hoffentlich nur die best practice und tatsächlich auf Fehler ausgerichtete Coding Standards und nicht Formatierung, dass diese Regeln einfach über eure Projekte gelegt werden und geguckt wird was passiert denn hier. Vielleicht werden Plug-in Autoren informiert von wegen hier. Kommatibilität ist nicht mehr gegeben oder da hast ein Fehler oder was auch immer. Das heißt es kümmert sich auch jemand anderes um euren Code. Was haben wir vielleicht hoffentlich bitte gerne gelernt? Coding Standards sind cool. Benutzt die? Es ist aber nicht alles oder nichts. Ihr müsst nicht exzessierende Standards nutzen und das war es. Ihr könnt die anpassen. Ihr könnt euch Terry-Picking-mäßig alles so zusammenkonfigurieren, wie ihr das möchtet und so ein kleiner Hinweis Wordpress selbst nutzt die Coding Standards, was natürlich naheliegend ist, aber erst seit einem halben Jahr was nicht so cool ist. Das heißt es gibt eine ganze Menge an Violations. Vielleicht hat ja jemand morgen Lust in den Contributing Sessions das einfach ein bisschen zu fixen. Dann könnte man sich irgendwo am Tisch zusammensetzen, per PCS über Wordpress laufen lassen, pickt sich ein paar Dateien raus und versucht den Code den Regeln entsprechend zu gestalten. Vielen Dank. Das war's von mir. Vielen Dank lieber Thorsten. Wir haben noch ein paar Minuten für Fragen. Hi Thorsten, danke erstmal für die coole Übersicht. Eine Frage. Wir sollten das mitbringen. Ja. Ich habe es auch dabei, aber das war mir dann doch ein bisschen zu warm. Wir können vielleicht gleich noch ein Foto machen mit den Handtuchlöten. Ich hatte eben mal kurz gestern, ich habe keinen Handtuch gesehen, deswegen... Vielleicht nochmal ganz kurz fürs Video um das Handtuch. Für diejenigen, die später noch zuschauen. Kurz erklären, weil dein Ton wird aufs Video aufgenommen. Ja, es kam die Frage, es stand in der Session Beschreibung, dass Leute Handtücher mitbringen sollten. Es spielte sich halt auf den Titel auf Pernhalter durch die Galaxis ab und jeder, der es kennt, weiß, warum. Wer es nicht weiß, könnte sich halt mal die Bücher durchlesen oder ein Film anschauen. Ich habe gestern gehört, dass manche Leute einfach nur einen Nerdy hinweist und ich dachte, dass so mehr Leute kommen. Super, Dankeschön. Habt ihr sonst noch Fragen? Außer jetzt zu Handtüchern. Also es ist eher eine Anmerkung, nicht unbedingt eine Frage. Wer zum Beispiel PRPS Dorm oder andere größere Ideas verwendet, der kann diese Coding-Standards direkt während der Entwicklung schon prüfen lassen. Also bei PRPS Dorm gibt es ja ganz, ganz viele Fehler, die am eingezeigt werden und man kann diesen Coding-Standards und sieht schon beim Programmieren so mit einer Gestrichelinie unten drunter, wo man dagegen verstößt. Und ich kann das nur jedem Entwickler empfehlen, weil man fängt an, sehr viel besseren Code zu schreiben schon während dem Schreiben und kriegt da nicht am Ende erst mal 100 Fehlern gezeigt, die man dann fixen muss. Also mir hat das sehr viel geholfen, einfach direkt besseren Code zu schreiben. Und das ist halt bei mir mittlerweile, also ich mache die Fehler gar nicht mehr, weil ich sofort das direkt schreibe mit direkt gezeigt, da hast du noch irgendwie ein Leerzeichen vergessen oder du hast eine Funktion verwendet, die du nicht verwendest oder anderes. Genau, dann nochmal fürs Video kurz. Also der Hinweis, dass viele Editoren und Ideas ermöglichen quasi direkt in dem Editor selber die Coding-Standards zu nutzen und visuell anzuzeigen, wo was nicht stimmt. Mein Hinweis da wäre aber, da wo es möglich ist, vielleicht nicht die Regeln zu nutzen, die man tatsächlich nutzt, sondern sich im Editor nur zu nutzen, weil alles was irgendwie formatierungsmäßig ist, kann man ja automatisch fixen lassen. Zum Beispiel über den Editor selber. PRPStorm hat ein Reformat Feature, eine Funktionalität. Ich möchte nicht überall wissen, wenn ich gerade Code schreibe, wo ein Leerzeichen zu wenig oder zu viel ist oder ich einen Semi-Code vergessen habe, wenn ich es eh sicherstelle, dass es halt nachher so aussieht wie es soll. Aber auf jeden Fall, es ist, man kann wirklich die Coding-Standards beim entwickeln immersiv nutzen und dabei, dass man das eingetrichtet bekommt und nicht einfach nur einmal, jeden Tag irgendwo am Ende bis Tag, sich da mal da war was falsch, sondern direkt beim Schreiben, ach ja stimmt, da muss ich das so und so machen. Das ist auf jeden Fall ein guter Hinweis. Wunderbar, also wenn wir keine weiteren Fragen jetzt bestehen, Thorsten ist ja sicherlich bis Sonntag noch hier, gerne auch zwischendurch, ihn einfach mal ansprechen, wenn ihr Fragen habt. Dann sage ich vielen Dank für eure Teilnahme. Vielen Dank, Peter Lamberg. Er spricht über WordPress im Konzern. Über corporate...