Namenskonventionen

Auf den ersten Blick mögen Namenskonventionen zweitrangig erscheinen, jedoch erweisen sie sich gerade bei größeren Systemen als ausgesprochen wertvoll, da sie die Lesbarkeit deutlich erhöhen.

Dies wird recht gut deutlich an einem Beispiel aus Bertrand Meyers Buch ``Reusable Software''. Zunächst hatte die Bibliothek nur wenige Klassen und bei jeder wurden die Namen in enger Anlehnung an die jeweilige Klasse gewählt:

Klasse	Operationen
STACK	top	push	pop
ARRAY	entry	enter
QUEUE	oldest	add	remove_oldest
H_TABLE	value	insert	delete

Wenn jedoch die Größe der Bibliothek anwächst, ist diese Lösung nicht glücklich, weil der Lernaufwand für jede neue betrachtete Klasse immens ist. Standardisierte Namen erleichtern hingegen die Orientierung, ohne daß dazu jeweils der entsprechende Eintrag im Referenzmanual im Vorfeld studiert werden muß. Und so endete die Eiffel-Bibliothek bei folgender Namensvergabe:

Klasse	Operationen
STACK	item	put	remove
ARRAY	item	put
QUEUE	item	put	remove
H_TABLE	item	put	remove

Genauso wie in der Eiffel-Bibliothek wurde auch bei der Ulmer Oberon-Bibliothek sehr auf durchgehende Namenskonventionen geachtet, die sich allerdings analog erst im Laufe der Zeit ergeben haben, wenngleich einige Konventionen auch auf Modula-2 zurückgehen:

• Module, Typen und Prozeduren beginnen mit einem Großbuchstaben. Konstanten, Variablen, Parameter und Komponenten eines Verbundes beginnen mit einem Kleinbuchstaben. Bei Namen, die aus mehreren Wörtern bestehen, beginnen die weiteren Wörter jeweils mit einem Großbuchstaben.

• Module erhalten Hauptwörter als Namen. Dabei sollte das Hauptwort in Plural stehen, wenn es sich um Module handelt, die Abstraktionen definieren, für die mehrere Implementierungen denkbar sind, oder die sich um einen abstrakten Datentyp ranken. Beispiele: Streams (allgemeine Abstraktion mit vielen Implementierungen) und Memory (Modul mit genau einer Implementierung, das den Adreßraum verwaltet).

• Abstrakte Datentypen erhalten typischerweise die Singularform des zugehörigen Moduls. Zeigertypen erhalten keine besondere Endung. Verbundtypen, die zu einem Zeigertyp gehören, übernehmen den Namen des Zeigertyps und erhalten die Endung Rec. Beispiele: Stream und StreamRec.

• Für Prozeduren werden überwiegend Verben verwendet. Im Fall von Attributabfragen sind jedoch auch Hauptwörter und Adjektive denkbar. Einige Verben haben in der Bibliothek eine durchgängige Bedeutung:

  
  
  

  Add	Hinzufügen eines Objekts in eine Datenstruktur.
  Close	Beendigung einer Beziehung.
  Create	Anlegen eines Objekts.
  Get	Abfragen eines Attributes.
  Init	Verbindung eines existierenden Objekts mit einer Schnittstelle.
  Open	Anlegen eines Objekts und Eröffnung einer Beziehung, die später explizit geschlossen werden sollte.
  Remove	Entfernen eines Objekts.
  Set	Setzen eines Attributes.

  
  
  

  Teilweise werden die Verben durch ein nachfolgendes Hauptwort näher spezifiziert. Allerdings sollte es generell vermieden werden, das Hauptwort des Modulnamens zu wiederholen, da es ohnehin angegeben werden muß.

Ein weiteres Problem sind potentielle Namenskonflikte bei den Modulnamen, wenn mehrere Parteien unabhängig voneinander Beiträge zu einer größeren Bibliothek leisten. Sehr sinnvoll sind hier die hierarchischen Modulnamen, die beispielsweise Perl und Java anbieten. Sie lassen insbesondere auch gleichzeitig eine funktions- oder anbieterorientierte Strukturierung in Schichten erkennen. Im Prinzip ist es auch möglich, bei anderen Programmiersprachen die Modul- oder Typnamen zu hierarchisieren, indem Konventionen längere Präfixe vorschreiben.

Dies geschieht auch teilweise in der Ulmer Oberon-Bibliothek. So beginnen alle Module aus der Schicht sys mit dem Präfix Sys, UNIX-spezifische Module mit Unix und das Internet unterstützende Module mit Inet.