Richtlinien zur Formatierung von Delphi Code
Über nichts können sich eingefleischte Programmierer mehr aufregen als über die Formatierung von Source-Code. Der Grund für dieses seltsame Verhalten ist wahrscheinlich darin zu sehen, dass eine gute und konsistente Formatierung des Source-Codes die Effizienz des Programmierers entscheidend steigern kann. Bekommt man ein Programm zur Bearbeitung, das nicht den eigenen Formatregeln entspricht, so ist es ziemlich zeitraubend, sich in das jeweilige Programm einzuarbeiten (vor allem wenn der Stil nicht nur anders, sondern auch objektiv schlecht ist). Darum ist es gerade bei Arbeitsgruppen wichtig, dass alle Mitarbeiter den selben Stil verwenden.
Persönl. Anmerkung: |
Ich löse dieses Dilemma grundsätzlich so, dass ich fremden Source-Code zuerst nach meinen Regeln formatiere, bevor ich mich mit dem Code auseinander setze. Das kostet zwar anfangs Zeit, die man aber durch die höhere Effizienz sehr schnell wieder zurück gewinnt. Natürlich zahlt sich diese Vorgangsweise nur aus, wenn man an fremdem Code etwas ändern muss, oder die Zusammenhänge verstehen muss. |
Die in der folgenden Tabelle zusammengefassten Regeln sind natürlich nicht zwingend (und weichen von den offiziellen Borland-Regeln in einigen Punkten ab). Sie haben sich aber im Laufe von vielen Jahren an Programmiertätigkeit bewährt.
|
Details |
Beispiele |
Header im Source-Code |
Jedes Programm muss einen Header haben, der aus
- dem Banner mit dem Programmnamen, dem Namen des Programmierers, dem Beginn der Arbeiten und dem Datum der letzten Änderung,
- der Revision History und
- eventuell notwendigen Compiler-Switches
besteht. |
Beispiel |
Kopfzeilen der Prozeduren und Funktionen |
Prozedur- und Funktionsdeklarationen sind mit einem fixen Rahmen zu
umgeben, der unmittelbar oberhalb der Deklaration einen (*****) Kommentar
mit 80 Zeichen Länge enthält, und unmittelbar unterhalb die Dokumentation
der Parameter und er Funktion der Routine. |
Beispiel |
Einrückungen |
Einrückungen sind ein leidiges und sehr wichtiges Kapitel, das sehr oft zum "Religionskrieg"
ausartet. Die folgenden Regeln erzeugen sehr gut lesbaren Code (Beispiel):
-
Grundsätzlich immer genau zwei Zeichen einrücken (Ausnahme bei
if
then else)
-
Die zu einem Anweisungsblock gehörenden begin
und end haben dieselbe Einrückungsweite
als die Statements (siehe Beispiel 1)
-
If then else statements unterliegen
einer speziellen Einrückungsregel:
(1) wenn nur ein then
ohne else folgt, so wird der
bedingte Codeblock ganz normal eingerückt, das then
bleibt in der if-Zeile (siehe
Beispiel
2)
(2) wenn ein else
folgt, dann werden die beiden Code-Blöcke "gleichberechtigt" unter
einander geschrieben (Beispiel 3).
Hinweis: Diese Vorgangsweise ermöglicht es auch in langen if
then else-Konstruktionen gleich beim if
zu sehen ob noch ein else
kommt.
(3) längere else if-Leitern werden so geschrieben, dass die else
if statements untereinander stehen (Beispiel
4).
|
Beispiel 1
Beispiel 2
Beispiel 3
Beispiel 4 |
Zyklische Referenzen |
Zyklische Referenzen zwischen mehreren Units sind absolut zu vermeiden. Eine zyklische Referenz entsteht dadurch, dass eine Routine aus Unit A ein Unterprogramm der Unit B aufruft; dieses ruft eine Routine aus Unit C auf, die ihrerseits wiederum eine Routine der Unit A aufruft. Solche zyklischen Referenzen können dazu führen, dass der Programmcode nicht mehr übersetzbar wird. |
|
Variablendeklarationen |
Die Deklaration von Variablen hat so zu erfolgen, dass die Variablennamen
und die Typen in einer Spalte untereinnander stehen. Der Doppelpunkt hat
getrennt durch ein Leerzeichen vor dem Typbezeichner zu stehen.
Variablennamen: kurze (1 oder 2 Buchstaben) Bezeichner NUR
für Schleifenzähler und für Hilfsvariable, die nur in einem
begrenztem Kontekt (über wenige Sourcezeilen) benützt werden.
Variablennamen die in Prozedur- und Funktionsdeklarationen stehen, müssen
längere, für sich sprechende Namen haben. |
Beispiel |
Keine Tabs im Sourcecode |
Tabs im Sourcecode verhindern die Portierbarkeit und sind durch Blanks zu ersetzen. |
|
Kommentare |
Kommentare in ausnahmslos in Englisch anzubringen |
|
Code nach end. |
Nach dem abschließenden end.
eines Pascal-Programms darf kein weiterer Text mehr stehen (weder Code
noch Kommentar). |
|
|