Object Pascal Style Guide – Von Charles Calvert
(Object Pascal Coding Style Guide – Übersetzt von: Tommy Tong)
Wir sind uns bewusst, dass viele etablierte Studios oder Einzelpersonen ihre eigenen Programmierpraktiken haben, die von den in diesem Artikel beschriebenen abweichen. Wir empfehlen jedoch dringend, dass Sie ein Tool verwenden, um Ihren Code in Code im Borland-Stil zu konvertieren, und ihn dann an Borland senden. PRoject JEDI oder ein anderes öffentliches Quellcode-Repository. Wir möchten Sie nicht dazu zwingen, Ihre Gewohnheiten zu ändern, bestehen jedoch darauf, dass der gesamte Code, der mit Borland-Produkten funktioniert, den in diesem Artikel beschriebenen Gewohnheiten folgt.
Object Pascal ist eine wunderschöne Designsprache. Eine gute Lesbarkeit ist einer seiner Vorteile. Die in diesem Artikel entwickelten Standards verbessern die Lesbarkeit von Object Pascal-Code. Wenn Entwickler diese in diesem Artikel gezeigten einfachen Gewohnheiten befolgen, werden sie auch zu Standards, von denen alle Delphi-Entwickler profitieren, die einen einheitlichen und lesbaren Codierungsstil verwenden. Bemühungen zur Durchsetzung dieser Standards werden den Wert des Quellcodes für Entwickler erhöhen, insbesondere während der Wartungs- und Debugging-Zyklusphasen.
Obwohl wir an den in diesem Artikel propagierten Stil glauben und ihn bewundern, unterstützen wir ihn nicht unbedingt, weil er an sich richtig und in anderen falsch ist. Wir glauben jedoch, dass der von der überwiegenden Mehrheit der Entwickler befolgte Standard seine Gültigkeit hat, weshalb wir diesen Stil weiterhin unterstützen und beibehalten. Das menschliche Gehirn passt sich ständig an Standards an und findet Wege, vertraute Muster schnell zu organisieren, sodass ihre Bedeutung schnell und effizient verstanden werden kann. Es ist diese Anforderung, die Standards etabliert, die es einer großen Anzahl von Menschen so einfach wie möglich machen, Code zu lesen. Wenn Ihnen unsere Richtlinien zum ersten Mal unbekannt vorkommen, bitten wir Sie, eine Weile dabei zu bleiben, und Sie werden feststellen, dass Sie sich daran gewöhnen. Wenn Sie möchten, können Sie auch Ihren eigenen Stil beibehalten und ihn mit einem Programm konvertieren, das unseren Standards entspricht. Anschließend können Sie Ihren Code an Borland oder andere Repositories senden.
Einige Texteditoren wie Visual SlickEdit können Ihnen dabei helfen, Ihren Code in einem bestimmten Stil zu formatieren.
Ein von Egbert van Nes entwickelter kostenloser Formatierer ist verfügbar unter:
http://www.slm.wau.nl/wkao/delforexp.html
Ein weiteres kommerzielles Programm für Delphi ist CrackerJax:
http://www.kineticsoftware.com/html/products.html
-------------------------------------------------- ----
1.0 Einführung
Dieser Artikel ist kein Versuch, Syntaxregeln für die Object Pascal-Sprache zu definieren. Zum Beispiel: Es ist illegal, das Siegel „;“ vor else zu setzen; der Compiler lässt diese Verwendung nicht zu. Daher werde ich in diesem Artikel nicht auf die Grammatikregeln eingehen. Ziel dieses Artikels ist es, angemessenes Verhalten dort zu definieren, wo die Sprache Wahlmöglichkeiten bietet. Normalerweise schweige ich, wenn es nur eine Kontrollmethode gibt.
1.1 Hintergrund
Die in diesem Artikel vorgestellten Richtlinien basieren auf einem Teil des Delphi-Quellcodes. Der Delphi-Quellcode folgt genau diesen Richtlinien. Wenn Sie einen Verstoß gegen diese Grundsätze feststellen, sollten diese Grundsätze und nicht der unsichere Quellcode Ihre Richtlinie sein. Sie können jedoch den Originalcode als Ergänzung zu diesen Prinzipien verwenden, um zumindest einen allgemeinen Überblick über die Form Ihres eigenen Codes zu erhalten.
1.2 Danke
Die Formate in diesem Artikel basieren auf Arbeiten zur Definition von Stilstandards für die Java-Sprache. Java hat keinen Einfluss auf die Regeln zur Formatierung des Object Pascal-Quellcodes, die Dokumentation auf der Sun-Website ist jedoch die Grundlage für diesen Artikel. An einigen besonderen Stellen wurden Stil und Format dieses Artikels stark von „A Coding Style Guide for Java WorkShop and Java Studio Programming“ (Achut Reddy, „Coding Guide for Java WorkShop and Java Studio“) inspiriert. Den Artikel finden Sie unter dieser URL: http://www.sun.com/workshop/java/wp-coding
Das Delphi-Team hat einen wesentlichen Beitrag zur Fertigstellung dieses Artikels geleistet. Ohne ihre Hilfe wäre dieser Artikel tatsächlich nicht fertiggestellt worden.
2.0 Quelldateien
Der Object Pascal-Quellcode ist hauptsächlich in Einzelquelldateien und Projektdateien unterteilt und alle folgen der gleichen Konvention. Delphi-Projektdateien haben die Erweiterung .DPR. Es ist die Hauptdatei des Projekts. Jede in einem Projekt verwendete Unit-Datei hat die Erweiterung .PAS. Auch andere Dateien wie Batchdateien, HTML-Dateien oder DLLs können im Projekt eine Rolle spielen, dieser Artikel behandelt jedoch nur Projektdateien und Unit-Dateien.
2.1 Benennung der Quelldatei
Object Pascal unterstützt lange Dateinamen. Wenn Sie aus mehreren Wörtern einen einzigen Namen bilden, verwenden Sie am besten für jedes Wort einen Anfangsbuchstaben: MyFile.pas. Dies wird als Klammer oder camelCase betrachtet. Erweiterungen sollten in Kleinbuchstaben angegeben werden. Aus historischen Gründen verwendet Delphi-Quellcode häufig das 8:3-Namensmuster, Entwickler müssen sich jedoch nicht auf die oben genannten Regeln beschränken und auf die Verwendung des Delphi-Teams zurückgreifen.
Wenn Sie eine C/C++-Header-Datei übersetzen, sollte die zu übersetzende Pascal-Datei denselben Hauptdateinamen wie die C/C++-Header-Datei behalten und .PAS als Erweiterung verwenden. Zum Beispiel: Windows.h -> Windows.pas. Wenn die Pascal-Syntax Sie dazu zwingt, mehrere Header-Dateien in einer einzigen Unit-Datei zusammenzufassen, wird der Dateiname der Header-Datei, die die anderen Header-Dateien enthält, als Name der neuen Unit-Datei verwendet. Beispiel: Windows.h enthält die Datei WinBase.h, dann heißt die neue Unit-Datei Windows.pas.
2.2 Organisation der Quelldatei
Alle Unit-Dateien von Object Pascal sollten die folgenden Elemente in der folgenden Reihenfolge enthalten:
Kommentare zum Urheberrechts-/Identitätsblock
Einheitenname
Schnittstellensegment
Implementierungsteil
Ein Terminator „Ende“.
Zwischen jedem Abschnitt sollte mindestens eine Leerzeile stehen.
Andere Elemente sollten in der Reihenfolge strukturiert werden, die Sie für am besten halten. Aber das Copyright sollte ganz am Anfang der Datei stehen, dann der Unit-Name, dann alle bedingten Definitionen, Compiler-Anweisungen oder Include-Anweisungen und dann die used-Klausel:
{************************************************ * *****}
{ }
{Borland Delphi Visual Component Library}
{ }
{ Copyright (c) 1995,98 Inprise Corporation }
{ }
{************************************************ * *****}
Einheit Tasten;
{$S-,W-,R-}
{$C VORLADEN}
Schnittstelle
verwendet
Fenster, Nachrichten, Klassen,
Steuerelemente, Formulare, Grafiken,
StdStrgs, ExtStrgs, CommStrg;
Wenn Sie den Abschnitt „type“ vor den Abschnitt „const“ setzen oder beides mischen, hat dies keine Auswirkung.
Der Implementierungsteil muss zuerst die Implementierung schreiben, dann die Uses-Klausel und dann andere Include-Deklarationen oder andere Indikatoren:
Durchführung
verwendet
Consts, SysUtils, ActnList,
ImgList;
{$R BUTTONS.RES}
2.2.1 Kommentare zum Urheberrechts-/Identitätsblock
Jede Quelldatei sollte mit einem Blockkommentar beginnen, der Versionsinformationen und einen Standard-Copyright-Hinweis enthält. Versionsinformationen können wie folgt aussehen:
{************************************************ * *****}
{ }
{ Widgets in Hülle und Fülle }
{ }
{ Copyright (c) 1995,98 Ihr Unternehmen }
{ }
{************************************************ * *****}
Der Urheberrechtsvermerk muss mindestens die folgenden Zeilen enthalten:
Copyright (C) Jahr Copyright-Inhaber
Wenn Sie als Dritter Software für Borland entwickeln, können Sie am Ende des Urheberrechts Ihren eigenen Namen hinzufügen:
{************************************************ * *****}
{ }
{Borland Delphi Visual Component Library}
{ Copyright (c) 1995,99 Borland International }
{Erstellt von Project JEDI}
{ }
{************************************************ * *****}
2.2.2 Einheitendeklaration
Jede Unit-Datei muss eine Unit-Deklaration haben. Einheit ist ein reserviertes Wort und muss daher in Kleinbuchstaben geschrieben werden. Der Name der Einheit kann in gemischter Groß- und Kleinschreibung angegeben werden, muss jedoch mit dem Dateinamen der Einheitendatei identisch sein. Zum Beispiel:
Einheit MyUnit;
Dann sollte der Name der Unit-Datei MyUnit.pas lauten. Im Dateisystem dient es als Eintrag für diese Datei.
2.2.3 used-Anweisung
Innerhalb einer Einheit sollten Verwendungsdeklarationen mit kleineren Verwendungen gebootstrappt werden. Der referenzierte Einheitenname folgt der Groß-/Kleinschreibungskonvention, die verwendet wird, wenn er in einer eigenen Einheit definiert ist:
nutztMyUnit;
Jeder Einheitenname wird durch ein Komma vom benachbarten Einheitennamen getrennt, und auf den letzten Einheitennamen folgt ein Semikolon:
verwendet
Windows, SysUtils, Klassen, Grafiken, Steuerelemente, Formulare,
TypInfo;
Es ist auch richtig, den Einheitennamen ab der nächsten Verwendungszeile hinzuzufügen und den Einheitennamen direkt nach den Verwendungen hinzuzufügen.
verwendet Windows, SysUtils, Klassen, Grafiken, Steuerelemente, Formulare,
TypInfo;
Sie können Ihre Liste mit Einheitennamen so formatieren, dass sie innerhalb der 80-Zeichen-Grenze liegt oder eine Zeile pro Einheitenname enthält.
2.2.4 Klassen- und Schnittstellendefinitionen
Klassendefinitionen beginnen mit zwei Leerzeichen, gefolgt von einem Präfix „T“. Das Präfix sollte groß geschrieben werden und jedes eingebettete Wort sollte mit einem Großbuchstaben beginnen. Verwenden Sie im Object Pascal-Quellcode nicht das Tabulatorzeichen „Tab“. Beispiel:
TMyClass
Folgen Sie dem Bezeichner mit einem Leerzeichen, dann mit einem Gleichheitszeichen und dann mit dem Wort „class“, das in Kleinbuchstaben geschrieben sein sollte:
TMyClass = Klasse
Wenn Ihre Klasse von einem Vorfahren erbt, müssen Sie linke und rechte Klammern hinzufügen, die die Vorfahrenklasse enthalten:
TMyClass = Klasse(TObject)
Bereichsindikatoren sind zwei Leerzeichen vom Rand entfernt und erscheinen in der folgenden Reihenfolge:
TMyClass = clss(TObject)
Privat
schützen
öffentlich
veröffentlicht
Ende;
Daten werden normalerweise nur im privaten Bereich deklariert und ihre Bezeichner beginnen mit „F“. Alle derartigen Anweisungen müssen 4 Leerzeichen vom Rand entfernt sein:
TMyClass = Klasse (TObject)
Privat
FMyDate: Ganzzahl;
Funktion GetDate: Integer;
procedure SetData(Value: Integer);
öffentlich
veröffentlicht
Eigenschaft MyData: Integer read GetData write SetData;
Ende ;
Für Schnittstellen gelten dieselben Regeln wie für ihre Gegenstücke, mit der Ausnahme, dass Sie Bereichsindikatoren und private Daten ignorieren und das Wort „Schnittstelle“ anstelle des Wortes „Klasse“ verwenden sollten.
Namenskonvention
Mit Ausnahme reservierter Wörter und Indikatoren, die in Kleinbuchstaben geschrieben sind, sollten alle Pascal-Bezeichner das CamelCase-Format verwenden, d. h. der erste Buchstabe jedes Bezeichners sollte großgeschrieben werden, und der erste Buchstabe eingebetteter Wörter sollte ebenfalls großgeschrieben werden. Das Gleiche gilt für Abkürzungen das nimmt nur den ersten Buchstaben.
MyIdentifier
MyFTPClass
Die wichtigste Ausnahme von dieser Regel sind Header-Dateiübersetzungen, die den Namenskonventionen in den ursprünglichen Header-Dateien folgen sollten. Zum Beispiel:
WM_LBUTTONDOWN, wm_LButtonDown nicht schreiben.
Verwenden Sie außer bei Übersetzungen von Header-Dateien keine Unterstriche zur Trennung von Wörtern. Klassennamen sollten Substantive oder Nominalphrasen sein. Der Name der Schnittstelle oder Klasse hängt vom offensichtlichen Zweck und der Verwendung der Schnittstelle ab.
Guter Name:
AddressForm, ArrayIndexOutOfBoundsException
Schlechte Namen:
ManageLayout //Verbphrase verwenden
delphi_is_new_to_me //Unterstreichung verwenden
3.1 Benennung der Einheiten
Siehe Einheitendeklaration
3.2 Klassen-/Schnittstellenbenennung
Siehe Klassen-/Schnittstellendeklaration
3.3 Domänen-/Feldbenennung
Verwenden Sie das CamelCase-Format. Beginnen Sie mit einem großen „F“ und deklarieren Sie alle Daten als privat, indem Sie Eigenschaften oder Getter und Setter verwenden, um öffentlichen Zugriff zu ermöglichen. Beispiel: Verwenden Sie den Namen GetSomething, um eine Funktion zu benennen, die ein internes Feld/Feldwert zurückgibt, und verwenden Sie SetSomething, um eine Prozedur zu benennen, die ein Feld/Feldwert festlegt.
Verwenden Sie in const-Abschnitten nicht alle Großbuchstaben, es sei denn, dies ist für die Übersetzung der Header-Datei erforderlich.
Da Delphi in Kalifornien entwickelt wurde, raten wir von der Verwendung von Token ab, sofern diese nicht für die Übersetzung von Header-Dateien erforderlich sind.
richtig:
FMyString: string;
Falsch:
lpstrMyString: string;
Selbstverständlich bleibt die ungarische Nomenklatur bei der Definition des Aufzählungstyps erhalten:
TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp,
bkYes, bkNo, bkClose, bkAbort, bkRetry,
bkignore, bkAll);
In diesem Fall wird vor jedem Element dieses Aufzählungstyps das Zeichen bk eingefügt. bk bedeutet ButtonKind.
Vermeiden Sie beim Erwägen von Namenskonventionen die Verwendung von Namen mit nur einem Zeichen, mit Ausnahme von Nullzeitvariablen und Schleifenvariablen.
Vermeiden Sie die Verwendung der Variablen „l“ (L), da diese auf einem Drucker oder einem Monitor nur schwer von „1“ (eins) zu unterscheiden ist.
3.4 Methodenbenennung
Für die Methodenbenennung wird auch das CamelCase-Format verwendet. Die Konventionen für die Benennung von Methoden entsprechen denen für die Benennung nicht konstanter Felder, sie können jedoch vom Kontext unterschieden werden. Die Benennung von Methoden sollte die Verwendung von Verben oder Verbphrasen erzwingen. Zum Beispiel:
//Gute Methodenbenennung:
ShowStatus, DrawCircle, AddLayoutComponent
//Schlechte Methodenbenennung:
MouseButton //Nominalphrase, keine Beschreibungsfunktion
drawCircle //Mit Kleinbuchstaben beginnen
add_layout_component //Unterstreichung wird verwendet
//Die Funktionen der folgenden Methoden sind nicht klar genug. Startet es die Ausführung eines Dienstes (besser: StartServer) oder stellt es fest, ob ein Dienst ausgeführt wird (besser: IsServerRunning)?
ServerRunning //Verb-Phrase, aber kein Befehl
Eine Methode zum Abrufen oder Festlegen einiger Klasseneigenschaften sollte GetProperty bzw. SetProperty heißen, wobei Property den Namen der Eigenschaft darstellt. Zum Beispiel:
GetHeight, SetHeight
Eine Methode, die eine boolesche Eigenschaft einer Klasse testet, sollte IsVisible heißen, wobei Visible den Namen der Eigenschaft darstellt. Zum Beispiel:
IsResizable, IsVisible
3.5 Lokale Variablen benennen
Die Benennungsregeln für lokale Variablen sind dieselben wie für Felder/Felder, außer dass „F“ nicht verwendet wird. Siehe Abschnitt 3.3.
3.6 Reservierte Wörter
Reservierte Wörter und Indikatoren sollten ausschließlich in Kleinbuchstaben geschrieben werden. Das kann manchmal etwas verwirrend sein. Beispiel: Integer ist ein Bezeichner und wird mit einem Großbuchstaben angezeigt. Die für die Zeichenfolge reservierten Wörter sind alle in Kleinbuchstaben geschrieben.
3.7 Typdeklaration
Alle Typnamendeklarationen beginnen mit dem Buchstaben T und folgen demselben Namen wie die Klasse.
4.0 Leerraumnutzung
4.1 Leerzeilen
Leerzeilen können die Lesbarkeit verbessern, indem sie logisch zusammengehörige Codesegmente gruppieren. An folgenden Stellen kann auch eine Leerzeile verwendet werden:
Nach dem Copyright-Kommentarblock folgen die Paketdeklaration (Paket) und der Importabschnitt (Import).
zwischen Klassendeklarationen.
zwischen Methodendeklarationen.
4.2 Leerzeichen
Object Pascal ist eine sehr klare und lesbare Sprache. Normalerweise müssen Sie nicht viele Leerzeichen hinzufügen, um Zeilen in Ihrem Code zu trennen. Die folgenden Artikel enthalten einige Richtlinien für die Verwendung von Leerzeichen:
4.2.2 Leerzeichen sollten nicht verwendet werden:
Zwischen dem Methodennamen und der öffnenden Klammer;
Vor oder nach dem .(Punkt)-Operator;
zwischen einem unären Operator und seinem Operanden;
Zwischen einem Typ und dem Ausdruck, den er umwandelt;
nach der linken Klammer und vor der rechten Klammer;
nach der linken eckigen Klammer und vor der rechten eckigen Klammer;
vor einem Verbot;
Zum Beispiel:
//Richtige Verwendung:
function TMyClass.MyFunc(var Value: Integer);
MyPointer := @MyRecord;
MyClass := TMyClass(MyPointer);
MyInteger := MyIntegerArray[5];
//Falsche Verwendung:
function TMyClass.MyFunc( var Value: Integer );
MyPointer := @MyRecord;
MyClass := TMyClass (MyPointer);
MyInteger := MyIntegerArray [ 5 ] ;
4.3 Einrückung
Sie sollten alle Einrückungsebenen immer um zwei Leerzeichen einrücken. Mit anderen Worten: Die erste Ebene wird um zwei Leerzeichen eingerückt, die zweite Ebene wird um vier Leerzeichen eingerückt, die dritte Ebene wird um sechs Leerzeichen eingerückt ... Verwenden Sie nicht das Tabulatorzeichen Tab.
Natürlich gibt es noch ein paar Ausnahmen. Reservierte Wörter wie Einheit, Verwendung, Typ, Schnittstelle, Implementierung, Initialisierung und Finalisierung werden immer in Großbuchstaben geschrieben. Die letzte Endkennung der Zelle ist ebenfalls oberste Ebene. In der Projektdatei befinden sich das Programm sowie der Hauptanfang und das Hauptende ebenfalls im oberen Raster. Der Hauptblock begin..end muss um mindestens zwei Leerzeichen eingerückt werden.
4.4 Fortsetzung
Zeilen sollten auf 80 Spalten begrenzt sein. Zeilen mit mehr als 80 Spalten sollten in mehrere aufeinanderfolgende Zeilen aufgeteilt werden. Alle nachfolgenden Zeilen sollten auf die erste Zeile dieser Deklaration folgen und um zwei Leerzeichen eingerückt sein.
Zum Beispiel:
//richtig:
Funktion CreateWindowEx(dwExStyle: DWord;
lpClassName: PChar; lpWindowName: PChar;
dwStyle: DWORD; X, Y, nWidth, nHeight: Integer;
hWndParent: HWND; hMenu: HMENU;
lpParam: Zeiger): HWND; stdcall ;
wenn ((X = Y) oder (Y = X) oder
(Z = P) oder (F = J) dann
beginnen
S := J;
Ende ;
Umbrechen Sie keine Zeilen zwischen einem Parameter und seinem Typ, es sei denn, die Liste ist durch Kommas getrennt. In diesem Fall wird vor dem letzten Parameter umgebrochen, sodass der Typname in der nächsten Zeile beginnt. Zwischen dem Doppelpunkt und seiner Variablen sollte kein Leerzeichen stehen, und zwischen dem Doppelpunkt und dem Typnamen sollte ein Leerzeichen stehen.
//richtig:
procedure Foo(Param1: Integer; Param2: Integer);
//Fehler:
procedure Foo( Param :Integer; Param2:Integer);
Eine nachfolgende Zeile sollte nicht mit einem binären Operator beginnen. Vermeiden Sie es, eine Zeile dort abzuschneiden, wo normalerweise keine Leerzeichen vorkommen, z. B. zwischen einem Methodennamen und seiner öffnenden Klammer oder zwischen einem Array-Namen und seiner öffnenden Klammer. Wenn Sie in der oben genannten Situation Zeilen umbrechen müssen, brechen Sie die Zeile nach der öffnenden Klammer oder der öffnenden eckigen Klammer um. Platzieren Sie begin nicht in derselben Zeile wie anderer Code.
Zum Beispiel:
//Fehler:
while (LongExpression1 oder LongExpression2 ) beginnen
//DoSomething
//DoSomethingElse;
Ende ;
//richtig
while (LongExpression1 oder longExpression2) tun
beginnen
//DoSomething
//DoSomethingElse;
Ende ;
if (LongExpressiong1) oder
(LongExpression2) oder
(LongExpression3) dann
5,0 Kommentare
Die Object Pascal-Sprache unterstützt zwei Arten von Kommentaren: Block- und einzeilige Kommentare. Hier sind einige Richtlinien zur Verwendung von Anmerkungen:
·Es ist hilfreich, oben in der Einheit Kommentare zu platzieren, die den Zweck der Einheit erläutern
·Es ist hilfreich, Kommentare vor Klassendeklarationen zu platzieren
·Es ist hilfreich, Anmerkungen vor Methodendeklarationen festzulegen
·Vermeiden Sie Kommentare mit offensichtlicher Bedeutung
i := i + 1; //Füge eins zu i hinzu
·Denken Sie daran, dass leicht fehlinterpretierte Kommentare schädlicher sind als gar keine Kommentare.
·Vermeiden Sie es, Informationen in Kommentare einzufügen, die ungültig erscheinen
·Vermeiden Sie die Einbettung von Sternchen oder anderen typografischen Symbolen in die Ränder von Kommentaren
·Zero-Hour-Kommentare, also Kommentare, die geändert oder gelöscht werden müssen, sollten mit „???:“ davor gekennzeichnet werden, damit sie leicht zu finden sind. Konzeptionell sollten alle Zero-Time-Kommentare vor der Veröffentlichung des Programms gelöscht werden.
// ???: Ändern Sie dies, um Sort aufzurufen, wenn es behoben ist
List.MySort;
5.1 Kommentare blockieren
Object Pascal unterstützt zwei Arten von Blockkommentaren. Am häufigsten werden Kommentare verwendet, die in geschweifte Klammern {} eingeschlossen sind. Das Delphi-Team hat die Kommentare so kurz und einfach wie möglich gehalten. Beispiel: Sie sollten die Verwendung von Sternchen vermeiden, um in Ihren Kommentaren Muster oder Linien zu erzeugen. Verwenden Sie stattdessen Leerzeichen, um Ihre Kommentare zu trennen, genau wie in einem Textverarbeitungsdokument. Die Wörter in Ihrem Kommentar sollten in derselben Zeile wie die erste geschweifte Klammer beginnen, wie im folgenden Auszug aus DsgnIntf.pas:
{ TPropertyEditor
Bearbeitet eine Eigenschaft einer Komponente oder einer Liste von Komponenten.
im Objektinspektor ausgewählt
Der Editor wird basierend auf dem Typ erstellt
Eigenschaft, die je nach Typ bearbeitet wird
registriert von...
usw...
GetXxxValue
Ruft den Wert der ersten Eigenschaft in ab
Eigenschaften-Eigenschaft. Ruft die entsprechende Eigenschaft auf
TProperty GetXxxValue-Methode zum Abrufen der
Wert.
SetXxxValue Legt den Wert aller Eigenschaften fest
in der Properties-Eigenschaft
TProperty SetXxxxValue-Methoden zum Festlegen des Werts.
Blockkommentare werden häufig in Copyright-Kommentaren verwendet. Wird auch zum Auskommentieren einiger Codezeilen verwendet.
Der Methodendeklaration sollte ein Blockkommentar vorangestellt werden, der den Zweck der Methode erläutert.
Zum Beispiel:
// RICHTIG
{ TMyObject.MyMethod
Mit dieser Routine können Sie Code ausführen.
Prozedur TMyObject.MyMethod;
beginnen
Ende;
// FALSCH
Prozedur TMyObject.MyMethod;
{************************************************ * ****
TMyObject.MyMethod
Mit dieser Routine können Sie Code ausführen.
************************************************** ******}
beginnen
Ende;
Der zweite Blockkommentartyp enthält zwei Zeichen, Klammern und ein Sternchen: (* *). Dies wird manchmal als Stern-Klammer-Kommentar bezeichnet. Diese Anmerkungen sind im Allgemeinen nur während der Codeentwicklung nützlich und ihr Hauptvorteil besteht darin, dass sie es ermöglichen, dass verschachtelte Anmerkungen weniger als zwei Ebenen tief sind. Object Pascal unterstützt nicht die gleiche Art der Verschachtelung von Kommentaren, daher gibt es eigentlich nur eine Verschachtelungsebene: geschweifte Klammern in Sternklammern oder Sternklammern in geschweiften Klammern. Standard-Pascal-Annotationen anderer Typen innerhalb von Annotationen dieses Typs werden ignoriert, solange Sie sie nicht verschachteln. Daher können Sie diese Syntax verwenden, um einen großen Codeblock auszukommentieren, der sowohl Code als auch Kommentare enthält:
(* procedure TForm1.Button1Click(Sender: TObject);
beginnen
DoThis; // Den Prozess starten
DoThat; // Iteration fortsetzen
{ Wir brauchen hier eine Möglichkeit, Fehler zu melden, vielleicht mit
ein Versuch endlich blockieren ??? }
CallMoreCode; // Den Vorgang abschließen
Ende ; *)
In diesem Fall wird die gesamte Button1Click-Methode auskommentiert, einschließlich aller darin enthaltenen Unterkommentare.
5.2 Einzeilige Kommentare
Ein einzeiliger Kommentar besteht aus einem Kommentarzeichen // und seinem führenden Text, mit einem Leerzeichen zwischen dem Text und dem Kommentarzeichen. Wenn einzeilige Kommentare in anderen Zeilen als der Code stehen, müssen sie die gleiche Einrückungsstufe wie der Code haben. Sie können mehrere einzeilige Kommentare verwenden, um einen großen Kommentar zu bilden.
Vor einem einzeiligen Kommentar oder einer Kommentargruppe ist eine Leerzeile erforderlich, es sei denn, es handelt sich um die erste Zeile eines Blocks. Wenn Kommentare für mehrere Anweisungen verwendet werden, sollte hinter Kommentaren und Kommentargruppen eine Leerzeile stehen. Wenn der Kommentar nur die Aussage in der darauffolgenden Zeile erläutert, muss ihm keine Leerzeile folgen.
Zum Beispiel:
// Öffnen Sie die Datenbank
Tabelle1.Öffnen;
Den Code-Deklarationen, die sie erklären, können auch einzeilige Kommentare folgen. Solche Kommentare werden manchmal als Tracking-Kommentare bezeichnet. Zwischen ihnen und dem Code muss mindestens ein Leerzeichen stehen. Wenn mehrere Trace-Kommentare gleichzeitig in einem Codeblock erscheinen, müssen diese Kommentare ausgerichtet werden.
Zum Beispiel:
if ( nicht IsVisible) then
Beenden; // nichts zu tun
Inc(StrLength); // Platz für Nullterminator reservieren
Vermeiden Sie es, Kommentare in jeder Zeile des ausführbaren Codes nachzuverfolgen. Normalerweise ist es am besten, die Verwendung von Kommentaren zwischen den begin..end-Blöcken einer Methode oder Funktion einzuschränken oder sie sogar leer zu lassen. Lange Kommentare können in Blockkommentaren vor der Definition von Methoden und Funktionen stehen.
Art
6.1 Organisation des Unterrichts
Die Organisation der Klassengremien sollte der folgenden Reihenfolge folgen:
·Domänen-/Felddeklaration
·Methodendeklaration
·Attributdefinition
Domänen/Felder, Eigenschaften und Methoden sollten alphabetisch nach ihren Namen indiziert werden.
6.1.1 Zugriffsebenen
Mit Ausnahme des von der IDE generierten Codes sollten die Bereichsbezeichner für Klassen in der folgenden Reihenfolge vorliegen:
·private Aussage
·protect-Anweisung
·öffentliche Erklärung
·Veröffentlichte Stellungnahme
In Object Pascal haben Klassenmitglieder vier Zugriffsebenen: veröffentlicht, öffentlich, geschützt und privat – in der Reihenfolge abnehmender Zugriffsmöglichkeiten. Die Standardzugriffsebene wird veröffentlicht. Im Allgemeinen sollte einem Mitglied die niedrigste Zugriffsebene zugewiesen werden, die für es am besten geeignet ist. Beispiel: Mitglieder, auf die nur andere Klassen in derselben Unit zugreifen können, sollten als privat deklariert werden. Gleichzeitig bietet die Deklaration von Mitgliedern mit niedrigen Zugriffsebenen dem Compiler auch die Möglichkeit, die Optimierung zu verbessern. Andererseits erschwert die Verwendung niedriger Zugriffsebenen natürlich die Erweiterung von Unterklassen. Wenn Grund zu der Annahme besteht, dass eine Klasse irgendwann in der Zukunft untergeordnet wird, sollten die Mitglieder, die von der Unterklasse geerbt und erweitert werden müssen, als geschützt deklariert werden. Eigenschaften, die für den Zugriff auf private Daten verwendet werden, können diesen Schutz ebenfalls bieten.
Sie sollten den öffentlichen Zugriff auf die Daten verbieten. Daten werden normalerweise im privaten Abschnitt deklariert und jeder öffentliche Zugriff darauf sollte über die Methoden oder Eigenschaften GetXXX, SetXXX erfolgen.
6.1.8 Konstruktordeklaration
Methoden müssen nach alphabetischem Index sortiert werden. Es ist richtig, die Konstruktoren und Destruktoren am Anfang des öffentlichen Abschnitts zu platzieren oder sie alphabetisch anzuordnen.
Wenn mehrere Konstruktoren vorhanden sind oder Sie mehrere Konstruktoren mit demselben Namen verwenden, sollten diese gemäß der Parameterliste angeordnet werden, wobei der mit den wenigsten Parametern vor dem mit den meisten Parametern steht. Das heißt, wenn ein Konstruktor ohne Parameter vorhanden ist, muss dieser zuerst erscheinen. Um die beste Kompatibilität mit C++Builder zu gewährleisten, sollte die Parameterliste des Konstruktors eindeutig sein. C++ ruft einen Konstruktor nicht anhand seines Namens auf, daher besteht die einzige Möglichkeit, mehrere Konstruktoren zu unterscheiden, in der Argumentliste.
6.2 Methodendeklaration
Methodendeklarationen sollten nach Möglichkeit in einer einzigen Zeile erscheinen.
Zum Beispiel:
Beispiele:
Prozedur ImageUpdate(Image img, infoflags: Integer,
x: Ganzzahl, y: Ganzzahl, w: Ganzzahl, h: Ganzzahl)
7.0-Schnittstelle
Eine Schnittstellendeklaration hat die gleiche Form wie eine Klassendeklaration:
InterfaceName = Schnittstelle ([ geerbte Schnittstelle ])
InterfaceBody
Ende ;
Schnittstellendeklarationen sollten um zwei Leerzeichen, Schnittstellenkörper um vier Leerzeichen und Endzeichen um zwei Leerzeichen eingerückt werden.
Die Schnittstellendeklaration enthält keine Felder/Felder. Es können jedoch Attribute auftreten.
Alle Schnittstellenmethoden sind von Natur aus öffentlich und abstrakt, und es besteht keine Notwendigkeit, solche Schlüsselwörter in die Schnittstellendeklaration aufzunehmen.
Sofern nicht anders angegeben, haben Schnittstellendeklarationen denselben Stil wie Deklarationen desselben Typs.
7.1 Organisation der Schnittstellenstelle
Der Schnittstellenkörper kann in der folgenden Reihenfolge organisiert werden:
·Deklaration der Schnittstellenmethode
·Deklaration von Schnittstellenattributen
Schnittstellenmethoden und -eigenschaften werden im gleichen Stil wie Klassen deklariert.
8,0 Aussage
Eine Anweisung ist eine oder mehrere Codezeilen, die mit einem Siegel enden. Eine einzelne Anweisung hat nur eine Bannnummer und eine zusammengesetzte Anweisung hat mehrere Bannnamen.
//Dies ist eine einzelne Anweisung:
A := B;
//Dies ist eine zusammengesetzte Aussage:
beginnen
B := C;
A := B;
Ende ;
8.0.1 Einzeldeklaration
Wenn eine einzelne Anweisung umgebrochen werden muss, muss sie um zwei Leerzeichen gegenüber der vorherigen Zeile eingerückt werden.
//Zum Beispiel:
MeinWert :=
MyValue + (SomeVeryLongStatement / OtherLongStatement);
8.1.1 Zuweisungs- und Ausdrucksdeklarationen
Es kann höchstens eine Anweisung pro Zeile geben.
Zum Beispiel:
a := b + c; Inc( Count );
a := b + c; //Richtig
Inc(Count); //Richtig
8.1.2 Lokale Variablendeklaration
Lokale Variablen verwenden auch das CamelCase-Format. Verwenden Sie nicht den Anführer „F“, der für Felder/Felder in Klassendeklarationen reserviert ist.
Zum Beispiel:
var
MeineDaten: Ganzzahl;
MyString: string ;
Sie können mehrere Variablen desselben Typs in derselben Zeile deklarieren:
var
ArraySize, ArrayCount: Integer;
Diese Deklarationsgewohnheit wird in Klassendeklarationen nicht empfohlen.
8.1.3 Array-Deklaration
Es ist üblich, vor der öffnenden Klammer und nach der schließenden Klammer immer ein Leerzeichen zu setzen:
Typ
TMyArray = Array [0..100] von Char;
8.2.3 if-Anweisung
Die if-Anweisung muss in mindestens zwei Zeilen erscheinen:
Zum Beispiel:
//Fehler:
wenn A = B, dann DoSomething;
//richtig
wenn A = B dann
Mach etwas;
Wenn es sich um eine zusammengesetzte if-Anweisung handelt, sollte für jedes Trennzeichen eine neue Zeile vorhanden sein:
//Fehler:
Wenn A = B, dann beginnen
Mach etwas;
DoSomethingElse;
Ende , sonst beginnen
Tun Sie dies;
DoThat;
Ende ;
//richtig
wenn A = B dann
beginnen
Mach etwas;
DoSomethingElse;
Ende
anders
beginnen
Tun Sie dies;
DoThat;
Ende ;
Es können einige Variationen des Folgenden übernommen werden:
//richtig
wenn Bedingung dann
beginnen
Tun Sie dies;
Ende sonst
beginnen
DoThat;
Ende ;
//richtig
wenn Bedingung dann
beginnen
Tun Sie dies;
Ende
anders
Mach etwas;
//richtig
wenn Bedingung dann
beginnen
Tun Sie dies;
Ende sonst
Etwas tun;
// Die folgende Methode ist vielleicht nicht wichtig, aber sie ist lobenswert:
wenn Bedingung dann
Tun Sie dies
sonst DoThat;
8.2.4 zur Aussage
Beispiel:
// FALSCH
für i := 0 bis 10 beginnen
Mach etwas;
DoSomethingElse;
Ende ;
// RICHTIG
für i := 0 bis 10 do
beginnen
Mach etwas;
DoSomethingElse;
Ende ;
8.2.5 while-Anweisung
Beispiel:
// FALSCH
während x < ; j beginnt
Mach etwas;
DoSomethingElse;
Ende ;
// RICHTIG
während x < ;
beginnen
Mach etwas;
DoSomethingElse;
Ende ;
8.2.6 wiederholen bis Anweisung
Beispiel:
// RICHTIG
wiederholen
x := j;
j := UpdateValue;
bis j = 25;
8.2.7 Fallerklärung
Beispiel:
// RICHTIG
Fall Control.Align von
alLeft, alNone: NewRange := Max(NewRange, Position);
alRight: Inc(AlignMargin, Control.Width);
Ende ;
// RICHTIG
Fall x von
CSStart:
beginnen
j := UpdateValue;
Ende ;
csBegin: x := j;
csTimeOut:
beginnen
j := x;
x := UpdateValue;
Ende ;
Ende ;
// RICHTIG
case ScrollCode von
SB_LINEUP, SB_LINEDOWN:
beginnen
Incr := FIncrement div FLineDiv;
FinalIncr := FIncrement mod FLineDiv;
Count := FLineDiv;
Ende ;
SB_PAGEUP, SB_PAGEDOWN:
beginnen
Incr := FPageIncrement;
FinalIncr := Incr mod FPageDiv;
Incr := Incr div FPageDiv;
Count := FPageDiv;
Ende ;
anders
Anzahl := 0;
Incr := 0;
FinalIncr := 0;
Ende ;
8.2.8 try-Anweisung
//Richtig
versuchen
versuchen
EnumThreadWindows(CurrentThreadID, @Disable, 0);
Ergebnis := TaskWindowList;
außer
EnableTaskWindows(TaskWindowList);
erheben ;
Ende ;
Endlich
TaskWindowList := SaveWindowList;
TaskActiveWindow := SaveActiveWindow;
Ende ;
Blog des Autors: http://blog.csdn.net/sailerbai/