Der Epina Delphi-Kurs bietet Ihnen eine allgemeine Einführung in das Programmieren mit Delphi/Pascal. Mit vielen ausgearbeiteten Beispielen können Sie direkt in die Delphi-Programmierung einsteigen. Mehr dazu finden Sie hier....

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).  

 
 

Last Update: 2008-09-09