Codierungsstandards stellen dem Entwicklungsteam hauptsächlich eine Programmierrichtlinie zur Verfügung, damit Projektentwickler bei der Programmierung ein einheitliches Format haben, an das sie sich halten können. Auf diese Weise kann der von jedem Programmierer im Entwicklungsteam geschriebene Code von anderen verstanden werden, wodurch die Wartbarkeit des Codes verbessert wird und ein von mehreren Personen geschriebener Softwaresatz so erstellt wird, als wäre er von einer Person geschrieben worden, was den Code einfacher macht zu verstehen. Dies erfordert, dass jeder einen einheitlichen Codierungsstil verwendet. Der Grund, warum die Einführung dieser Standards ein Klischee ist, liegt darin, dass einige neue Entwickler, die dem Projektentwicklungsteam beitreten, möglicherweise nicht mit den Codierungsstandards von Delphi vertraut sind. Diese Standards werden hier in den folgenden Kategorien vorgestellt: 1. Allgemeine Regeln für das Quellcodeformat 2. Prozeduren und Funktionen 3. Benennung von Dateien, Formularen und Datenmodulen 4. Benennung von Paketen und Komponenten Allgemeine Regeln für das Quellcodeformat Die Einrückung erfolgt auf jeder Ebene. Es gibt zwei Zwischenräume zwischen ihnen. Platzieren Sie im Quellcode keine Tabulatorzeichen. Dies liegt daran, dass die Breite des Tabulatorzeichens je nach Einstellungen und Codeverwaltungsprogrammen (Drucken, Dokumentation, Versionskontrolle usw.) variiert. Ränder sind auf 80 Zeichen eingestellt. Im Allgemeinen überschreitet der Quellcode beim Schreiben eines Wortes nicht den Spielraum, diese Regel ist jedoch flexibler. Wenn möglich, sollten Anweisungen, die länger als eine Zeile sind, mit Kommas oder Operatoren umschlossen werden. Nach einem Zeilenumbruch sollte dieser um zwei Zeichen eingerückt werden. Bei eckigen Klammern darf zwischen der öffnenden Klammer und dem nächsten Zeichen kein Leerzeichen stehen. Ebenso gibt es kein Leerzeichen zwischen der schließenden Klammer und dem vorherigen Zeichen. Das folgende Beispiel zeigt korrekte und falsche Leerzeichen. CallPROcedure(Parameters); // Falsch! CallProcedure (Parameters); // Reservierte Wörter und Schlüsselwörter Objekt Die reservierten Wörter und Schlüsselwörter der Pascal-Sprache sind immer vollständig kleingeschrieben. Die begin...endbegin-Anweisung muss in einer eigenen Zeile stehen. Beispielsweise ist die erste Zeile unten falsch, aber die zweite Zeile ist korrekt: for i:=0 to 10 do beginStatement end// Falsch, begin steht in derselben Zeile wie for i:=0 to 10 do //Rect ! begin in Ein Sonderfall dieser Regel in beginStatementend in einer anderen Zeile ist, wenn begin Teil einer else-Anweisung ist. Beispiel: if Condition thenbeginStatement endelse beginStatement; die endend-Anweisung steht immer in einer separaten Zeile. Wenn begin nicht Teil einer else-Anweisung ist, wird die entsprechende end-Anweisung um denselben Betrag eingerückt wie die begin-Anweisung. Aussage (1) Die wahrscheinlichste Situation der if_then_else-Anweisung sollte in die then-Klausel und die unwahrscheinliche Situation in die else-Klausel eingefügt werden. Um viele if-Anweisungen zu vermeiden, verwenden Sie stattdessen case-Anweisungen. Wenn es mehr als 5 Ebenen gibt, verwenden Sie keine if-Anweisungen. Bitte verwenden Sie stattdessen eine klarere Methode. Verwenden Sie in if-Anweisungen keine zusätzlichen Klammern. Im Quellcode werden Klammern nur dann verwendet, wenn sie wirklich benötigt werden. Zum Beispiel: if (I=42) then // Falsch, Klammern sind überflüssig. if (I=42) oder (J=42) then // Richtig, Klammern müssen verwendet werden. Wenn in der if-Anweisung mehrere Bedingungen getestet werden müssen, Sie sollten von rechts nach links in der Reihenfolge der Rechenkomplexität anordnen. Dadurch kann der Code die Kurzschluss-Schätzlogik des Compilers voll ausnutzen. Wenn Bedingung1 schneller als Bedingung2 und Bedingung2 schneller als Bedingung3 ist, sollte die if-Anweisung wie folgt aufgebaut sein: if Bedingung1 und Bedingung2 und Bedingung3 then(2) case_else-Anweisung Die Konstanten für jeden Fall in der case-Anweisung sollten numerisch oder alphabetisch angeordnet sein Befehl. Die Aktionsanweisung für jede Situation sollte kurz sein und normalerweise nicht mehr als 4 bis 5 Codezeilen umfassen. Wenn die Aktion zu komplex ist, sollte der Code in einer separaten Prozedur oder Funktion platziert werden. Die else-Klausel einer case-Anweisung wird nur für Standardfälle oder zur Fehlererkennung verwendet. (3) Die while-Anweisung empfiehlt, den Exit-Prozess nicht zum Verlassen der while-Schleife zu verwenden. Bei Bedarf sollte eine Schleifenbedingung verwendet werden, um die Schleife zu verlassen. Der gesamte Code, der die While-Schleife initialisiert, sollte sich vor dem While-Eintrag befinden und nicht durch irrelevante Anweisungen getrennt sein. Eventuelle Hilfsarbeiten für den Betrieb sollten unmittelbar nach dem Zyklus durchgeführt werden. (4) for-Anweisung Wenn die Anzahl der Schleifen bestimmt wird, sollte die for-Anweisung anstelle der while-Anweisung verwendet werden. (5) Wiederholungsanweisung Die Wiederholungsanweisung ähnelt einer While-Schleife und folgt denselben Regeln. (6) with-Anweisung Die with-Anweisung sollte mit Vorsicht verwendet werden. Vermeiden Sie die übermäßige Verwendung von with-Anweisungen, insbesondere wenn Sie mehrere Objekte oder Datensätze innerhalb einer with-Anweisung verwenden. Beispiel: Mit Record1 und Record2 können diese Situationen Programmierer leicht verwirren und das Debuggen erschweren. Strukturierte AusnahmebehandlungDie Ausnahmebehandlung wird hauptsächlich zur Fehlerkorrektur und zum Schutz von Ressourcen verwendet. Dies bedeutet, dass überall dort, wo Ressourcen zugewiesen werden, try...finally verwendet werden muss, um sicherzustellen, dass die Ressourcen freigegeben werden. Es gibt jedoch Ausnahmen, wenn Ressourcen im Anfangs-/Endteil der Einheit oder im Konstruktor/Destruktor des Objekts zugewiesen/freigegeben werden. (1) Verwendung von try...finally Wann immer möglich, sollte jede Ressourcenzuweisung mit der try...finally-Struktur übereinstimmen. Zum Beispiel: //Der folgende Code kann Fehler verursachen SomeClass1: = TSomeClass.Create;SomeClass2: = TSomeClass.Create;try{do some code}finallySomeClass.Free;SomeClass.Free;end;//Eine sichere Lösung für die oben genannte Ressource Zuordnung ist: SomeClass1: = TSomeClass Create;trySomeClass2: = TSomeClass Create;try{do some code}finallySomeClass2.Free;end;finallySomeClass1.Free;end;(2) Verwendung von try...exclusive Wenn Sie einige Aufgaben ausführen möchten, wenn eine Ausnahme auftritt, können Sie try...exclusive verwenden. Normalerweise besteht keine Notwendigkeit, try... zu verwenden, außer um einfach eine Fehlermeldung anzuzeigen, da das Anwendungsobjekt dies automatisch basierend auf dem Kontext tun kann. Wenn Sie die Standard-Ausnahmebehandlung in der Klausel aktivieren möchten, können Sie die Ausnahme erneut auslösen. (3) Von der Verwendung von try...exclusive...else wird von der Verwendung von try...exclusive mit einer else-Klausel abgeraten, da dadurch alle Ausnahmen blockiert werden, einschließlich Ausnahmen, mit denen Sie nicht umgehen können.