5 Formatierung
Ein guter Entwickler sollte nicht nur funktionierenden Code entwickeln, sondern auch guten lesbaren Code, da ein guter lesbarer Code die Wartung und die Erweiterbarkeit einer Software deutlich verbessert. In einem Team müssen den Entwicklern die Formatierungsregeln bekannt sein, damit jeder Entwickler sich schnell im Code zu Recht finden kann. Diese Formatierungsregeln müssen mit dem Team abgesprochen werden, damit alle die gleichen Formatierungsregeln verwenden. Wir werden ein paar Standartformatierungsregeln uns anschauen, die man gut verwenden kann. Als erstes schauen wir uns die Dateiengröße an und sehen, dass große Projekte oft aus vielen große Dateien bestehen. Die meisten Dateien haben im Schnitt 200 Zeilen. Diese Größe ist ein guter Richtwert für eigene Projekte.
Um den Code gut lesbar zumachen, sollte man Leerzeilen einbauen. Die Leerzeilen haben den Vorteil, dass die Augen immer auf eine neue Zeile gerichtet werden und der Code dadurch auch strukturiert wird. Der Code sieht flüssiger aus, als ohne Leerzeilen. Man trennt die Package Deklaration, die lmport-Anweisungen und die Funktionen in einer Klasse mit Leerzeilen. Das ist vertikale Offenheit. Wenn vertikale Offenheit gilt, dann kann man die Bestandteile des Codes mehr im Zusammenhang setzen. Das heißt vertikale Dichte. Zusammenhängender Code wird untereinander ohne Leerzeile voneinander getrennt. Also zum Beispiel gibt es zwei Variablen, diese stehen direkt untereinander, weil die beiden Variablen zusammengehören. Ein weiterer Schritt für guten lesbaren Code ist der vertikale Abstand. Der Abstand zu zusammenhängenden Code sollte möglichst klein sein. Also sollte man nicht Variablendeklarationen irgendwo sinnlos im Code positionieren, sondern in der Nähe wo man diese verwendet. Zum Beispiel in Funktionen sollten lokale Variablen am Anfang stehen und in Schleifenanweisungen sollte man die Schleifenvariable deklarieren, da der Abstand zu der Verwendung der Variable sehr gering ist. Bei langen Funktionen können die Variablen auch vor der Schleife und vor der Funktion deklariert werden. Aber Instanzvariablen sollten immer am Beginn einer Klasse stehen. Sie werden von fast allen Methoden verwendet und sollten deswegen am Anfang der Klasse stehen. Auch abhängige Funktionen sollten untereinander stehen. Wenn zum Beispiel eine Funktion eine andere Funktion aufruft, dann sollte die aufgerufene Funktion unter der anderen stehen. Dieses gilt auch für Codeteile die sich sehr ähnlich, denn diese weisen eine konzeptionelle Affinität aus. Diese Codeteile sollten einem geringen vertikalen Abstand zu einander haben. Zum Beispiel wenn Funktionen einen gleichen Methodenkopf haben, dann aber andere Parameter übergeben bekommen als die andere Funktion. Es ist wichtig, dass der Code einer vertikalen Anordnung gleicht. Der Code sollte sich von oben nach unten lesen lassen, also sollten die Funktionen, welche als erstes Aufgerufen werden, auch als erstes im Code folgen. Man findet sich dadurch leichter im Code zurecht.
Die Horizontale Formatierung befasst sich mit der Zeilenbreite im Code. Die Zeilen sollten kurz sein. Am besten ist es, wenn man eine Zeilenbreite von maximal 120 Zeichen nimmt, da der Benutzer sonst sehr lange nach rechts scrollen muss. Das Scrollen stört den Lesefluss des Benutzers und kostet einen Entwickler Zeit und Nerven. Mit dem Whitespace kann der Entwickler zusammenhänge im Code gut verdeutlichen oder auch keine zusammenhänge im Code zeigen. Zum Beispiel bei der Zuweisung der Variablen, dort wird die Zuweisung mit einem Gleichheitszeichen und einem Leerzeichen zwischen der Variable und dem Wert getrennt. Vor dieser Trennung wird die Variablenzuweisung noch eingerückt nach innen in der Funktion. Man kann mit diesem Schritt gut getrennten Code zeigen. Aber auch umgekehrt geht das, wenn zum Beispiel der Funktionsname und die Funktionsklammer zusammen schreibt ohne diese mit einem Leerzeichen zu trennen. Man kann aber auch so die Parameter im Funktionskopf voneinander trennen, da jeder Parameter für sich steht. Eine andere Besonderheit ist, dass man mit Whitespaces die Reihenfolge von Codeaufrufe gut darstellen kann. Eine Gleichung ist so gut lesbar. Auch Variablendeklarationen sollten nicht eine allzu große Liste darstellen. Eine Alternative wäre die Variablendeklarationen auf mehrere Klassen aufzuteilen. Es ist sehr wichtig den Code einzurücken, da dadurch der Code nicht nur übersichtlicher sondern auch die Verarbeitung der Codestücke untereinander ersichtlich ist. Wir wissen genau, dass zum Beispiel der innere Codeblock als erstes verarbeitet wird und danach der äußere Codeblock. Beide Codeblöcke sind mit geschweiften Klammern voneinander getrennt. Also rückt man als erstes Funktionen ein, dann den Code der diese Funktion implementiert. Der Code besteht aus Bedingungen, Schleifen und Variablendeklarationen. Diese werden auch wieder untereinander eingerückt, auch wenn der Code nur aus einer Zeile besteht.
In einem Team gelten die Formatierungsregeln des Teams, nicht seine eigenen Formatierungsregeln, da jeder Entwickler gerne seine eigenen Regeln benutzen will. Das Team muss eine gemeinsame Basis finden.