Thiemos Archiv
- Thursday, 2012-01-05 21:54
- Ich habe mir im Laufe der Jahre meine ganz persönlichen, sprachunabhängigen Konventionen zur Quelltextformatierung (Coding Conventions) erarbeitet, die für alles gültig sind, was ich mache: Java, PHP, JavaScript, C++, selbst für CSS. Die Sprachen sind ja auch sehr ähnlich, also gilt auch für alle mehr oder weniger das Selbe.
- Variablen, Funktionsnamen, Klassen usw. werden grundsätzlich englisch benannt, auch wenn der Quelltext voraussichtlich nur von deutschsprachigen Programmierern gelesen wird. Das gilt auch für Datenbanktabellen. Die einzige Ausnahme davon sind Quelltextbeispiele (wie hier auf dieser Seite), die sich an ein deutschsprachiges Publikum richten.
- Kommentare sind im Gegensatz dazu deutsch, vor allem, da ich mich in meiner Muttersprache viel leichter ausdrücken kann. Außer natürlich, die Kommentare richten sich an ein internationales Publikum.
- Umlaute sollten vermieden werden, auch in Kommentaren. Gerade Java hat mich da sehr überrascht, denn obwohl die Sprache selbst ganz klar Unicode-zentriert ist, dürfen die Quelltextdateien in jedem beliebigen Zeichensatz verfasst sein. Konvertierungsprobleme sind nur durch Umschreiben sicher zu vermeiden, mit »ae« in Kommentaren und
\u00E4etc. in String-Literalen. - Geschweifte Klammern gehören grundsätzlich untereinander, nie ans Ende der Zeile.
Keine Ausnahmen.Einzige Ausnahme: CSS. - Einrückungen werden nie mit Tabulatoren gemacht sondern grundsätzlich mit Leerzeichen, da man sich nie darauf verlassen kann, wie Tabs dargestellt werden und es zwangsläufig zu Vermischungen und Chaos kommt. Eine verlässliche Formatierung erhält man nur, wenn man die Tabulatorzeichen gleich bei der Eingabe durch Leerzeichen ersetzen lässt. Jeder ernsthafte Quelltexteditor unterstützt das, genauso wie das schnelle Verändern der Einrückungstiefe mit Umschalt+Tab.
- Die Einrückungstiefe ist grundsätzlich geradzahlig, meist 2 oder 4 Leerzeichen, je nachdem, was in der Sprache am ehesten üblich ist. Bei PHP beispielsweise sind es 4, bei Java nur 2. Das ist dann auch einzuhalten, also auch keine Ausnahmen, um beispielsweise die Teile eines komplizierten if-Konstrukts untereinander auszurichten.
- In eine Zeile gehört immer nur ein Statement. Die Richtschnur lautet also, dass immer nur ein Semikolon in einer Zeile stehen darf. Konstrukte wie das
forsind natürlich eine Ausnahme. - Die Zeilenregel gilt genauso für das, was hinter Sprachkonstrukten wie
ifoderforfolgt. Deren Inhalt gehört ausnahmslos in die nächste Zeile, egal wie kurz er ist. - Bei sehr kurzen
ifmit nur einem Statement dürfen die geschweiften Klammern ausnahmsweise weggelassen werden. Aber wirklich nur, wenn sowohl die Bedingung (in der ersten Zeile) als auch der Inhalt (in der zweiten Zeile) sehr, sehr kurz sind. Im Zweifelsfall sollte man die zwei zusätzlichen Zeilen für die geschweiften Klammern in Kauf nehmen. - In runde Klammern gehören niemals Leerzeichen. Das macht man in Texten (so wie hier) ja auch nicht.
- Sprachkonstrukte werden von Funktions- und Methodenaufrufen durch das Setzen bzw. Weglassen eines Leerzeichens vor der runden Klammer unterschieden. Bei so etwas wie
abs(2.5)gehört die Klammer und die darin stehenden Argumente bzw. Parameter zur Methodensignatur.if (bedingung) { }oder gardo { } while (bedingung);sind dagegen keine Signaturen sondern strukturierende Elemente eines Sprachkonstrukts, so wie die geschweiften Klammern. - Alle Operatoren werden grundsätzlich mit Leerzeichen abgesetzt, also beispielsweise
b = (a + 1) * 3;oder (hier in einem spezifischen PHP-Beispiel)$ausgabe = "Zeile " . (i + 1) . ": " . $array[$i];. - Kurzformen wie
a++sollten vermieden werden, vor allem, wenn sie irgendwo in einem größeren Konstrukt untergehen. Ein einzeln stehendesanzahl++;in einer eigenen Zeile ist dagegen in Ordnung. Die ausgeschriebene Formanzahl = anzahl + 1;wäre in diesem Fall nicht unbedingt besser lesbar sondern aufgrund der Redundanz sogar fehleranfälliger. - Den trinären ?:-Operator verwende ich, allerdings nur, wenn das, was er tut, extrem kurz ist und in eine einzelne Zeile passt. So etwas wie
$className = $i % 2 ? "odd" : "even";ist beispielsweise in Ordnung. - Was für mich auch völlig in Ordnung ist, sind implizite Typkonvertierungen wie in
if (!objekt), obwohl man eigentlichif (objekt == null)schreiben sollte, oderif ($zahl), obwohl man eigentlichif ($zahl != 0)schreiben sollte. Java verbietet das, und das finde ich auch in Ordnung, aber das ist kein Grund für mich, es in Sprachen wie JavaScript oder PHP, die das erlauben, nicht trotzdem zu machen. Eine Ausnahme gibt es in PHP, wo ich inzwischen sehr häufig mitif (empty($variable))arbeite, da das sehr elegant die Warnungen vor undefinierten Variablen unterdrückt.
Kommentare zu diesem Beitrag können per E-Mail an den Autor gesandt werden.
* In Klammern grundsätzlich ein Leerzeichen zum Abgrenzen des Inhalts, dafür aber davor keins. Also zum Beispiel if( $objekt == null ); oder if( !$objekt ) oder b = ( a + 1 ) * 3;. Das erhöht IMHO die Lesbarkeit (Code hat nichts mit normaler Rechtschreibung zu tun).
* Trinäre ?:-Operatoren sind grundsätzlich ein No-Go, egal wie kurz.
if( ( ( a == null ) && ( b != null ) ) || ( ( a != null ) && ( b != null ) ) );
Ich sehe da nur noch eine verstreute Wolke von Sonderzeichen, aber keine Struktur mehr, tut mir leid. (Das ist nur ein Beispiel, ein paar Klammern darin könnte man natürlich ganz weg lassen.)