Namenskonventionen und Richtlinien für die Eclipse-Plattform:
org.eclipse.ant[.*] - Ant-UnterstützungDie folgenden Segmente für Paketnamen sind reserviert:
org.eclipse.compare[.*] - Unterstützung für Vergleiche
org.eclipse.core[.*] - Plattformkern
org.eclipse.debug[.*] - Debug
org.eclipse.help[.*] - Bedienerunterstützung
org.eclipse.jdi[.*] - Eclipse-Implementierung von JDI (Java Debug Interface - Java-Schnittstelle für Debug)
org.eclipse.jdt[.*] - Java-Entwicklungstools
org.eclipse.jface[.*] - JFace
org.eclipse.pde[.*] - PDE (Plug-in Development Environment - Umgebung für Plug-in-Entwicklung)
org.eclipse.search[.*] - Unterstützung für Suche
org.eclipse.swt[.*] - SWT (Standard Widget Toolkit)
org.eclipse.team[.*] - Teamunterstützung und Versions- und Konfigurationsverwaltung
org.eclipse.tomcat[.*] - Apache tomcat-Unterstützung
org.eclipse.ui[.*] - Workbench
org.eclipse.update[.*] - Aktualisierung/Installation
org.eclipse.webdav[.*] - WebDAV-Unterstützung
internal - Kennzeichnet ein internes Implementierungspaket, das keine API enthält.Diese Namen werden als Qualifikationsmerkmale verwendet und dürfen nur nach dem Hauptpaketnamen angegeben werden. Beispiele:
tests - Kennzeichnet ein Paket ohne API, das nur Testkomponenten enthält.
examples - Kennzeichnet ein Paket ohne API, das nur Beispiele enthält.
Die Verwendung in org.eclipse.core.internal.resources ist korrekt.An dieser Stelle sollte erläutert werden, wie die Eclipse-Plattform strukturiert ist. Sie besteht aus einem Kern und aus einer Benutzerschnittstelle. Alle Elemente, die als Kern klassifiziert sind, sind vom Fenstersystem unabhängig; Anwendungen und Plug-ins, die vom Kern und nicht von der Benutzerschnittstelle abhängig sind, können ohne Kopf ausgeführt werden. Die Unterscheidung zwischen Kern und Benutzerschnittstelle ist nicht mit der Unterscheidung zwischen API und Nicht-API identisch, denn sowohl der Kern als auch die Benutzerschnittstelle enthalten APIs. Die Benutzerschnittstellenkomponente der Eclipse-Plattform wird als "Workbench" bezeichnet. Die Workbench ist ein Benutzerschnittstellengerüst auf Dialogbasis für die Erstellung von Produkten mit ausgereiften Benutzerschnittstellen, die aus Plug-in-Komponenten aufgebaut sind. Die Workbench wird oberhalb von JFace, SWT und dem Plattformkern eingerichtet. SWT (Standard Widget Toolkit) ist ein maschinennahes, von der Betriebssystemplattform unabhängiges Mittel für die Kommunikation mit dem nativen System mit Fenstertechnik. JFace ist ein Benutzerschnittstellengerüst der mittleren Ebene, mit dem komplexe Benutzerschnittstellenelemente wie beispielsweise Anzeigefunktionen für Eigenschaften erstellt werden können. SWT und JFace sind per definitionem Benutzerschnittstellen. Die Java-Tools sind eine IDE (Integrated Development Environment - Integrierte Entwicklungsumgebung) für Java, die oberhalb der Workbench eingerichtet wird. End aside.
Die Verwendung in org.eclipse.internal.core.resources ist falsch, denn das Segment internal steht vor dem Hauptpaketnamen.
Die Verwendung in org.eclipse.core.resources.internal ist falsch, denn internal folgt nicht unmittelbar auf den Hauptpaketnamen.
API-Pakete API-Pakete enthalten Klassen und Schnittstellen, die für unabhängige Softwarehersteller verfügbar gemacht werden sollen. Die Namen der API-Pakete sollten für den Adressaten aussagekräftig sein. Die Anzahl der unterschiedlichen Pakete, die zu beachten sind, sollte möglichst gering sein, da bei einem Übermaß an API-Paketen schwer ermittelt werden kann, welche Pakete importiert werden müssen. In einem API-Paket, werden alle öffentlichen Klassen und Schnittstellen als API betrachtet. Die Namen von API-Paketen sollten die Segmente internal, tests oder examples nicht enthalten, damit keine Verwechslung mit dem Benennungsschema für Pakete eintritt, die keine APIs enthalten.
Interne Implementierungspakete: Alle Pakete, die zur Plattformimplementierung gehören, jedoch keine API enthalten, auf die ein Entwickler zugreifen muss, werden als interne Implementierungspakete betrachtet. Alle Implementierungspakete sollten mit dem Segment internal gekennzeichnet werden. Diese Kennung ist unmittelbar nach dem Hauptpaketnamen anzugeben. Entwicklern wird mitgeteilt, dass alle mit internal gekennzeichneten Pakete nicht für die Entwicklung bestimmt sind. (Bei einer einfachen Textsuche nach .internal. werden verdächtige Verweise in Quellendateien gefunden; analog ist das Vorkommen von "/internal/" in Dateien .class verdächtig).
Pakete mit Testprogrammen Alle Pakete, die Testprogramme enthalten, sollten mit dem Segment tests gekennzeichnet werden, das unmittelbar nach dem Hauptpaketnamen anzugeben ist. Vollständig automatisierte Tests sind der Normalfall. Daher würde beispielsweise das Paket org.eclipse.core.tests.resources automatisierte Tests für die API in org.eclipse.core.resources enthalten. Interaktive Tests (bei denen ein Tester anwesend sein muss) sollten mit dem Segment interactive gekennzeichnet werden, das als letztes Segment im Paketnamen anzugeben ist. Das Paket org.eclipse.core.tests.resources.interactive würde beispielsweise die entsprechenden interaktiven Tests enthalten.
Pakete mit Beispielen: Alle Pakete, die an Entwickler ausgelieferte Beispiel enthalten, sollten mit dem Segment examples gekennzeichnet sein, das unmittelbar nach dem Hauptpaketnamen anzugeben ist. Das Paket org.eclipse.swt.examples würde Beispiele für die Verwendung der SWT-API enthalten.
Weitere Regeln:
Klassennamen sollten Nomen in Groß-/Kleinschreibung sein, wobei der erste Buchstabe jedes internen Worts ein Großbuchstabe sein sollte. Versuchen Sie, ihre Klassennamen so einfach und aussagekräftig wie möglich zu definieren. Verwenden Sie vollständige Wörter, und vermeiden Sie Akronyme und Abkürzungen - es sei denn, die Abkürzung ist gebräuchlicher als die Langform (z. B. URL oder HTML).Bei Schnittstellennamen wird die Konvention befolgt, dass in allen Namen der Großbuchstabe I (für "Interface" = Schnittstelle) als Präfix verwendet wird, z. B. IWorkspace oder IIndex. Diese Konvention verbessert die Lesbarkeit des Codes, weil Schnittstellennamen leichter erkannt werden können. (Microsoft COM-Schnittstellen beachten diese Konvention ebenfalls.)Beispiele:
Klasse "Raster"
Klasse "ImageSprite"Wie die Klassennamen sollten auch die Namen von Schnittstellen mit einem Großbuchstaben beginnen.
Weitere Regeln:
Methoden sollten Verben in Groß-/Kleinschreibung sein, wobei der erste Buchstabe der Methode ein Kleinbuchstabe und der erste Buchstabe jedes internen Worts ein Großbuchstabe sein sollte.Weitere Regeln:Beispiele:
run();
runFast();
getBackground();
Mit Ausnahme von Variablen werden alle Exemplare, Klassen und Klassenkonstanten in Groß-/Kleinschreibung mit einem Kleinbuchstaben als Anfangsbuchstaben geschrieben. Interne Wörter beginnen mit Großbuchstaben. Variablennamen sollten - auch wenn dies zulässig ist - nicht mit einem Unterstreichungszeichen _ oder einem Dollarzeichen $ beginnen.(Hinweis: Die Konvention, dass die Namen von nicht konstanten Feldern das Zeichen f als Präfix erhalten - wie in fWidget - wird nicht mehr befolgt.)Variablennamen sollten möglichst aussagekräftig sein. Die Auswahl eines Variablennamens sollte mnemonisch orientiert sein, also dem potenziellen Betrachter Hinweise über den Verwendungszweck liefern. Variablennamen, die aus nur einem Buchstaben bestehen, sollten vermieden werden, es sei denn es handelt sich um temporäre Variablen für einen einmaligen Gebrauch. Allgemeine Namen für temporäre Variable sind i, j, k, m und n (für Integer) sowie c, d und e für Zeichen.
Beispiele:
int i;
char c;
float myWidth;
Die Namen von durch Variablen deklarierten Klassenkonstanten und von ANSI-Konstanten sollten ausschließlich in in Großbuchstaben geschrieben werden, wobei einzelne Wörter durch Unterstreichungszeichen (_) abzugrenzen sind.Beispiele:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
Der Plug-in-Namensbereich wird hierarchisch verwaltet. Bitte erstellen Sie kein Plug-in ohne die vorherige Zustimmung des Eigners, dem der einschließende Namensbereich zugeordnet ist.
Die Namen von Erweiterungspunkten, an denen mehrere Erweiterungen zu erwarten sind, sollten die Pluralform verwenden, also erstellungsprogramme statt erstellungsprogramm.