WCF2: Konsistenz bei der Entwicklung

  • WCF 2

Achtung: Diese Seite ist nur noch Teil eines Archivs und wird in Zukunft entfernt.

Viele Entwickler können zwar technisch entwickeln, an der Konsistenz hapert es aber nur zu oft. Nicht nur aus persönlichem Anlass möchte ich daher den Entwicklern mit diesem Artikel etwas mitgeben, wodurch sich die Konsistenz verbessert.

Mit der Konsistenz verhält es sich leider so wie mit der Rechtschreibung. Sie wird von Experten nicht nur empfohlen, sondern geradezu aufgedrängt (im positiven Sinne), allerdings viel zu selten bemängelt oder mit den entsprechenden Konsequenzen durchgesetzt. Demzufolge: Genauso, wie die Rechtschreibung im Abitur beachtet wird (kaum), so wird auch das Herstellen von Inkonsistenz fast nirgends in irgendeiner Form geahndet.

Das beliebteste Argument dabei: Es funktioniert doch.
Das mag stimmen, Funktion ist aber auch gar nicht das Ziel von Konsistenz. Das Ziel von Konsistenz ist, dass alles wie aus einem Guss wirkt und dementsprechend immer gleich aufgebaut wird. Und ja, auch dann kann man es noch soweit modifizieren, dass man erkennt, dass es etwas eigenes ist. Gerade wenn man ein Framework nutzt wie Community Framework, sollte man die Konsistenz nicht außer Acht lassen, denn WoltLab gibt sich alle Mühe, überall konsistent zu sein.

Ein paar Faustregeln, die später erläutert werden:
  • Eigenes CSS/Less vermeiden
  • Sprachvariablen gleich benennen wie WoltLab
  • Sprachinhalte in derselben Art angeben wie WoltLab
  • Template-Aufbau analog halten
  • MySQL-Abfragen analog aufbauen
  • Einrückungen und Leerzeilen korrekt vornehmen
Hält man sich daran, so ist ein konsistenter Aufbau praktisch schon garantiert.

Im Detail:
Eigenes CSS/Less vermeiden
Eigenes CSS oder LESS bedeutet immer, dass man etwas hinzufügt, was es im Framework noch nicht in dieser Form gibt. Es gilt daher, sich vorher zu informieren - d.h. entsprechende ähnliche Stellen abzusuchen - um nicht eventuell doch auf etwas schon vorhandenes zurückzugreifen. Das ist in der Tat nicht immer möglich, als Beispiel kann ich hier auch meine eigenen Plugins Slider-Box und Teaser-Box 2 nennen, welche teilweise einiges an eigenem LESS benötigen.
Grundsätzlich kann man Standardelemente aber bereits ohne vorhandenes LESS bzw. CSS lösen (wobei man als Entwickler immer LESS nutzen sollte - Konsistenz ;) ). Wenn man aber wirklich eigene Elemente benötigt, dann muss man auch darauf achten, dass es sich einerseits in die bisherigen Elemente von Community Framework gut einpflegt, ohne dass es wie ein Fremdkörper wirkt, andererseits aber auch stilunabhängig gut aussieht.
Anmerkungen wie "Inline-CSS vermeiden" nenne ich an dieser Stelle gar nicht, das sollte selbstverständlich sein!

Sprachvariablen gleich benennen wie WoltLab
Der Endbenutzer bekommt zwar im Idealfall nie Sprachvariablen zu Gesicht, dennoch sollten diese immer gleich aussehen. So hat WoltLab z.B. für ein Recht, etwas zu sehen, am Ende der Sprachvariable immer canView stehen. Das sollte auch bei eigenen Plugins so bleiben. Zudem werden vor diesem Ende, das beschreibt, was das Recht macht, mehrere Worte mit einem Unterstrich getrennt, z.B.: wcf.acp.group.option.user.my_awesome_plugin.canView

Sprachinhalte in derselben Art angeben wie WoltLab
Was der Endbenutzer dagegen sehr wohl sieht, sind die Texte der Sprachvariablen. Hier ist es ganz besonders wichtig für die Konsistenz, dass diese immer gleich bleibt. Ein Beispiel: WoltLab beginnt die Beschreibungen von Checkboxen (sofern welche angegeben sind), immer mit "Aktivieren Sie diese Option, wenn Sie [..]" im Deutschen und mit "By enabling this option [..]". Solche Textbausteine sollte man sich immer anschauen und dementsprechend ebenso verwenden.

Template-Aufbau analog halten
Für mich als Designer sind natürlich Templates sehr wichtig. Vor allem deren Aufbau. Bereits in der Vergangenheit hat man gesehen, dass es vielen Entwicklern egal zu sein scheint - oder dass sie es einfach nicht besser wissen - und sich daher einfach irgendein Template zusammenschustern, das vielleicht im Standarddesign funktioniert... allerdings in keinem anderen und dementsprechend immer Anpassungen benötigt.
Wichtig ist hier vor allem, dass man nach Möglichkeit keine eigenen Klassen nutzt, sondern bereits vorhandene von WoltLab. Auch der Aufbau eines Containers sollte immer gleich sein. Solch einen Aufbau habe ich z.B. in dieser Tutorialreihe bereits hier gezeigt.
Ein Beispiel für eine weitere Regel ist ganz einfach: Über jeden Event-Platzhalter kommt eine Leerzeile. Darunter jedoch keine. Auch wenn ein neuer Bereich beginnt, wird dieser mit einer Leerzeile vom vorherigen abgetrennt.

Am besten ist es hier - wie bei eigentlich allem - wenn man sich den Code von WoltLab selbst anschaut und sich daran orientiert.

MySQL-Abfragen analog aufbauen
Alle Abfragen über MySQL gehen durch einen Parser, damit der Grundaufbau einer jeden Abfrage gleich bleibt. Dinge wie Backticks (``) sind demnach nicht notwendig und auch gar nicht erwünscht, da sie eher zu Problemen führen. Solch einen Aufbau kann man sich bei WoltLab direkt anschauen:

PHP-Quellcode

  1. $sql = "SELECT COUNT(*) AS count
  2. FROM wcf".WCF_N."_group";
Wichtig hier zu sehen:
Nach einem SQL-Befehl (SELECT, FROM) kommt immer ein Tab, kein Leerzeichen. Zudem ist jeder SQL-Befehl immer in einer neuen Zeile zu finden, ab dem zweiten jeweils eingerückt. Das führt dazu, dass sie im Editor letztendlich direkt untereinander zu sehen sind (in dieselb Beispiel leider nicht). Damit kommen wir auch schon zum letzten Punkt...

Einrückungen und Leerzeilen korrekt vornehmen
WoltLab gibt zwingend eine Einrückung von 8 Zeichen als Tab vor, d.h. die Einrückungen funktionieren mit Tabs, wobei die Tab-Breite auf 8 Zeichen stehen muss. Eine Leerzeile hat zudem dieselbe Einrückung wie die Zeile davor. Hinter dem letzten Zeichen einer Zeile soll selbstverständlich keine Einrückung mehr vorhanden sein.
Dabei hilfreich ist die Anzeige dieser Steuerzeichen, die Tabs, Leerzeichen und Zeilenumbrüche anzeigt. In Notepad++ lässt sich diese z.B. über Ansicht -> Nicht druckbare Zeichen -> Alle anzeigen aktivieren, unter NetBeans z.B. unter View -> Show non-printable Characters. Wer einen anderen Editor nutzt, findet die Option einfach über Google. ;)
Leerzeilen sollten zudem unter jeder abgeschlossenen Funktion vorhanden sein. Das im Detail zu erklären (vor allem für LESS- und PHP-Dateien sowie Templates) würde hier den Rahmen sprengen.


P.S.: Ein persönlicher Anlass - wie Eingangs geschrieben - ist es für mich deshalb, weil ich beinahe täglich Plugins sehe, die zwar funktionieren, aber an allen Ecken und Enden inkonsistent sind. Das fängt bei Kleinigkeiten wie der Sprache an, geht aber auch teilweise soweit, dass für jeden - wirklich jeden - Stil eine Anpassung gemacht werden muss, weil der Template-Code so schlecht ist und nur eigene "Ideen" verwendet, die nicht durch den Standard von Community Framework abgedeckt sind.
Mit diesem Artikel hoffe ich, zumindest ein paar Entwickler dazu gebracht zu haben, sich zu überlegen, wie sie etwas umsetzen.

Leider ist es mir nicht möglich, an dieser Stelle alles in allen Einzelheiten zu behandeln. Einerseits weiß ich es insbesondere in PHP und JavaScript selbst nicht zu 100%, wie man alles konsistent nutzt, andererseits würde das allein für LESS und Templates fast schon ganze Bücher füllen. Das hier ist demnach mehr ein Anstoß an andere, sich vorhandenes anzuschauen und damit zu arbeiten bzw., wie schon angemerkt, zuerst einmal darüber nachzudenken, wie man etwas umsetzt - auch von der Seite der Konsistenz.

An dieser Stelle auch ein ganz großes Lob an TimWolla und Fighter456, die, auch mit Rücksprache zu mir, immer auf die Konsistenz bedacht sind! :)

Bei Fragen u.ä. stehe ich natürlich jederzeit gerne zur Verfügung.


Teil 6: Benutzergruppen-Einstellungen für die eigene Seite
Über den Autor
Ich bin Webentwickler in Stuttgart und administriere Server seit vielen Jahren. In diesem Blog erstelle ich hauptsächlich Tutorials für andere Webentwickler, Webdesigner und Serveradministratoren.
-------------------------------------------------------------------------------------------------------------------------------------
I’m a web developer in Stuttgart, Germany, and server administrator since many years. This blog mainly contains a tutorial set for other web developer, web designer and server administrators.

1.601 mal gelesen

Kommentare 1