Namensstil

Lesbarkeit

Texte einer formalen Sprache werden genauso für menschliche Leser  geschrieben, wie für maschinelle Leser.

Dieser Einsicht folgt auch der Stil  der Namensvergabe. Ein Autor eines Textes kann technisch gesehen (mit gewissen Einschränkungen) beliebige  Namen verwenden. Die Namen sollten aber so gewählt, daß sie menschlichen Lesern helfen, den Text zu verstehen.

Ein Name bezeichnet eine Entität, also ein irgendwie gegebenen „Etwas“. Der Name sollte den Sinn  dieser Entität wiedergeben. Damit dies möglich ist, muß die Entität erst einmal einen Sinn haben. Daher sollte der Autor die Entitäten so bilden, daß diese jeweils einen bestimmten Sinn haben und dann diesen Sinn durch den Namen beschreiben.

Der Name sollte dann möglichst kurz, verständlich, aussage-  und unterscheidungskräftig  sein. Anders gesagt: mit möglichst wenigen Zeichen soll möglichst viel nutzbare Information vermittelt werden.

Ob dieses Ziel erreicht wurde, kann ein maschineller Leser oft nicht erkennen. Hierzu muß meistens das Urteilsvermögen eines ausgebildeten Entwicklers herangezogen werden.

Kriterien

Einige Beispiele für Bezeichner sollen nun verdeutlich, welche Kriterien zur Wahl von Bezeichnern dienen können.

Beispiel   Bezeichner "wert_mit_information"

Das Ende "_mit_information" ist nicht aussagekräftig, da es selbstverständlich ist, daß ein verwendeter Wert im allgemeinen irgendeine Information darstellt. Hier sollte man kürzen auf "wert". Aber auch dieser Bezeichner ist noch nicht bestmöglich.

Beispiel   Bezeichner "wert"

Der Bezeichner "wert" ist viel zu allgemein. Viele  Bezeichner stehen für irgendeinen Wert. Daher muß dieser Bezeichner durch einen spezielleren ersetzt werden. Handelt es sich beispielsweise um einen an einer Kasse gegebenen Betrag in Euro, so kann dies im Bezeichner so gesagt werden und dieser kann dann lauten "gegebener_betrag_in_euro".

Beispiel   Bezeichner "gegebener_betrag_in_euro"

Dieser Bezeichner ist nun recht lang. Aber da der Länge diesmal eine größere Aussagekraft entspricht, ist sie noch zu billigen. Akzeptable Alternative sind "gegebener_betrag" (wenn die Währung ohnehin klar ist) oder "eurozahlbetrag". Der Name "betrag" alleine wäre schon wieder zu ungenau und zu allgemein. Je nachdem, welcher Aspekt in dem gegebenen Zusammenhang wichtiger ist, sind noch akzeptable und gleichzeitig kurze Namen "zahlbetrag" (wenn in diesem Zusammenhang auch Beträge in anderen Rollen vorkommen) oder "eurobetrag" (wenn in diesem Zusammenhang auch Beträge in anderen Währungen eine Rolle spielen).

Beispiel   Bezeichner "i"

Es erscheint zunächst als verfehlt, als Name nur "i" zu verwenden, da dies ja gar nichts aussagt. Dieser Name hat sich aber für „Zählerwerte“ (Index-Werte) eingebürgert. Er ist akzeptabel, wenn die genauere Bedeutung dieses Namens seinem Umfeld leicht entnommen werden kann. Oft steht solch ein „Index“ aber für etwas, z.B. für ein Jahr. Dann sollte doch besser der spezifischere Name, z.B. "jahr", verwendet werden.

Übungsfragen

In einer hypothetischen formalen Sprache werden beispielsweise Namen verwendet, die durch "name" 〈name 〉 ";" angemeldet werden müssen. Ein Programmierer könne außerdem in einer Zeile hinter "#" noch Notizen („Kommentare“) schreiben, die ignoriert werden (hinsichtlich der Bedeutung des Textes in der formalen Sprache), aber menschlichen Lesern der Einheit Erklärungen geben können. Vergleichen und bewerten Sie die beiden folgenden Stile der Namensvergabe und Kommentierung.

namen1

name b; # Benutzername 
name k; # Kennwort 

namen2

name benutzername; 
name kennwort;

Welche Namen werden jeweils verwendet? Wo werden Kommentare verwendet? Welche Namen sind verständlicher? Welches Vorgehen ist insgesamt zu befürworten?

Länge von Namen

In den meisten formalen Sprachen ist die Bindung eines Namens an eine bestimmte Bedeutung auf einen bestimmten Textbereich im Text einer Einheit eingeschränkt. Dieser Textbereich wird auch Gültigkeitsbereich  (scope ) genannt.

Namen mit kleinen Gültigkeitsbereichen sind immer relativ leicht verständlich, da man alle Fälle der Verwendung solcher Namen überblicken kann und notfalls so verstehen kann, um was es geht, auch wenn der Name selber wenig Informationen dazu gibt.

Auch Namen, die sehr häufig verwendet werden, prägen sich bald ein und müssen daher weniger umfangreich sein.

Namen mit großen Gültigkeitsbereich (in manchen formalen Sprachen „globale Namen“ oder „Namen mit externer Bindung“ genannt) dürfen auch schon einmal etwas länger sein, weil sie mehr Informationen über ihren Sinn transportieren müssen, denn der Leser kann nun nicht mehr leicht den gesamten Gültigkeitsbereich überblicken, um den Sinn eines Namens zu verstehen, er ist mehr auf die Information im Namen selber angewiesen.

Namen mit großem Gültigkeitsbereich müssen aussagekräftiger sein als Namen mit kleinem Gültigkeitsbereich, daher ist es passend, wenn Namen mit großem Gültigkeitsbereichbereich auch länger sind als Namen mit kleinem Gültigkeitsbereichbereich.

Zu lange Name können die Lesbarkeit von Code verschlechtern, da es Zeit kostet sie zu lesen und ihre Struktur von der Struktur einer Anweisung ablenken kann. Nicht ohne Grund werden in der Mathematik traditionell kurze Variablennamen verwendet, obwohl dort Speicherplatzmangel nie ein Problem war. Gerade Namen mit kleinem Gültigkeitsbereich, deren Sinn ziemlich klar ist, dürfen auch schon einmal aus nur einem Buchstaben oder aus nur wenigen Buchstaben bestehen.

Dokumentation von Namen

Die Beschreibung von Quelltext in Kommentaren oder externen Schriftwerken wird als Dokumentation  bezeichnet. Oft wird in Lehrbüchern betont, wie wichtig die Dokumentation sei. Doch es gibt auch gegenteilige Meinungen, denenzufolge man den Code selber so gut lesbar machen soll, daß keine zusätzliche Dokumentation mehr nötig ist. Ein Problem jeglicher Dokumentation ist es auch, daß es in der Praxis schwierig ist, sie immer wieder anzupassen, wenn sich der Code verändert.

„Meine persönliche Erfahrung mit zusätzlicher separater Dokumentation: Sie ist nie  auf gleichem Stand wie der Code und bringt de-fakto absolut überhaupt nichts ausser zusätzlicher Arbeit.

Ich habe schon mehrfach viel Dokumentation schreiben müssen, um dem vorgegebenen Prozess zu genügen und bis jetzt war die Arbeit immer  komplett für die Mülltonne. In den Teams, in denen ich bisher gearbeitet habe, wurde ich immer zuerst gefragt, bevor sich der Suchende die Mühe gemacht hat, in der Dokumentation nachzulesen.

Anstatt Zeit zu investieren, Dokumentation zu schreiben, würde ich die Zeit immer viel lieber für regelmässige Code-Reviews zu mehreren Personen ausgeben, um den Quellcode und die Schnittstellen noch besser lesbar zu machen. (...)

Inzwischen für alles was ich mache zu 100% selbst verantwortlich, dokumentiere ich in der Zwischenzeit fast nur noch Code, wenn ich einen ausgesprochen schrägen Hack eingebaut habe, der sich auf einen Blick nicht durchschauen lässt. Selbst dann fällt mir dabei dann oft auf, dass die Methodenbenennung einfach falsch war und das die Dokumentation nicht mehr notwendig ist, wenn ich sie

ändere.”

Carl Rosenberger ; Newsgroups: de.comp.objekt; Date: Mon, 15 Jul 2002 20:35:53 +0200; Message-ID: <agv4cf$uu6$02$1@news.t-online.com>

Es empfiehlt sich aber zumindestens bei Namen, deren Bedeutung nicht ganz offensichtlich ist, an der Stelle ihrer Definition  einmal kurz die beabsichtigte Bedeutung als Kommentar anzugeben. Wenn Code einige Monate nach der Herstellung wieder gelesen wird, zeigt es sich oft, daß Namen, deren Bedeutung bei der Niederschrift als ganz klar erschien, inzwischen nur noch schwer verständlich sind. Dann wünscht man sich schon manchmal, die beabsichtigte Bedeutung doch kurz beschrieben zu haben.

Die extreme Ausführung umfangreicher Dokumentation ist das literate programming, bei dem die Dokumentation zum Hauptsache wird, in die der eigentliche Code eingebettet wird. Das ist sinnvoll, wenn Code so stabil ist, daß er nur noch selten geändert wird und wenn der Code noch oft gelesen werden soll, etwa bei Code, der in Lehrbüchern veröffentlicht wird.

Wenn Quelltext entwickelt wird, dann wird er anfangs manchmal noch erheblich und häufiger überarbeitet (entsprechend der Bewegung von Teilchen kann man diesen dann als „heiß“ bezeichnen). Gibt es in diesem Stadium schon viel Dokumentation, dann wird deren Anpassung entweder Zusatzaufwand bedeuten (die „träge Masse“ des Codes ist erhöht) oder sie wird versäumt werden, was dann bewirken kann, daß der Code und seine Dokumentation nicht mehr zusammenpaßt, was vielleicht schlimmer ist als gar keine Dokumentation. Gleichzeitig ist ein Entwickler in dieser Phase aber gerade so sehr mit dem Code befaßt und vertraut, daß er zunächst kaum Dokumentation benötigt.

Nach einer Weile erreicht der Code dann eine gewisse Stabilität, er „kühlt ab“. Während der Entwickler nun seltener am Code arbeitet, vergißt er auch immer mehr Details. Jetzt ist es der richtig Moment, um Dokumentation hinzuzufügen. Da der Code nun nur noch seltener verändert werden wird, ist es jetzt auch eher erträglich, wenn die Änderung der Dokumentation dann auch zusätzliche Arbeit bedeutet. Gleichzeitig wird Dokumentation aber eher benötigt, da der Entwickler zu vergessen beginnt oder andere Entwickler mit dem Projekt zu tun haben. Wenn der Entwickler schon etwas  (aber noch nicht alles) vergessen hat, ist dies zum Schreiben der Dokumentation nicht ganz schädlich, denn während der Entwicklung erscheint ihm vieles als so selbstverständlich, daß ihm die Notwendigkeit der Dokumentation oft nicht einsichtig ist. Bemerkt er aber selber, daß er schon nachdenken muß, um etwas zu verstehen, dann wird ihm die Notwendigkeit einer Erklärung klar.

Nachdem frisch geschriebener Code sich einigermaßen „abgekühlt“ hat, also nicht mehr allzu oft geändert wird, sollte der Sinn der definierten Namen am Ort ihrer Definition erläutert werden, solange man sich noch daran erinnert. Entfallen kann solche Dokumentation, wenn der Sinn auch für Leser, die mit dem Code nicht vertraut sind, ganz sicher offensichtlich ist.

Bei kleineren Programmieraufgaben (mit Entwicklungszeiten von wenigen Stunden) heißt daß, das man die Dokumentation nicht ständig—während man die Lösung noch entwickelt—parallel überarbeiten muß, sondern diese dann schreiben kann, wenn die Lösung praktisch fertig ist.

Unnötige Kommentare können die Lesbarkeit von Code verschlechtern, da sie von dem Code ablenken und den Code insgesamt vergrößern und dadurch wieder unübersichtlicher machen.

Beispiele guter Namen

Die folgenden Namen sind Beispiele guter Namen, die kurz und knapp sagen, worum es geht. Am elegantesten ist es sicher, wenn es gelingt, den Sinn der benannten Entität mit einem kurzen Wort zu transportieren.

height Für die Höhe einer Fläche.

width Für die Breite einer Fläche.

looping Für eine Variable, die bestimmt, ob eine Schleife weiterhin durchlaufen wird.

running Für eine Variable, die bestimmt, ob ein Vorgang weiter laufen soll.

Beispiele traditioneller Namen

Die folgenden Namen sind Beispiele traditioneller (eingebürgerter) Namen.

dummy Für etwas, das nur aus formalen Gründen angegeben wird, aber keinen sinnvollen Wert darstellt.

foo Für einen beliebigen Namen, in Beispielen, in denen es eigentlich egal ist, worum es geht.

bar Für einen beliebigen Namen, in Beispielen, in denen es eigentlich egal ist, worum es geht.

xyzzy Für einen beliebigen Namen, in Beispielen, in denen es eigentlich egal ist, worum es geht.

Beliebte Kurznamen

Ganz kurze Name sind nur akzeptabel, wenn der Gültigkeitsbereich, in dem der Name verwendet wird, klein ist und man die Bedeutung sofort dem Zusammenhang entnehmen kann.

Manche Namen können aufgrund der alten FORTRAN -Konvention verstanden werden, nach der Variablen, deren Name ein bestimmter Buchstabe, wie "I" oder "N", ist, ganzzahlig sind. Diese FORTRAN -Konvention geht zurück auf noch ältere Konventionen der Mathematik.

i index —Eine ganzzahlige Variable, die Werte aus einem Bereich ganzer Zahlen annehmen kann.

n number —Eine ganzzahlige Variable, die eine bestimmte Anzahl (z.B. die Anzahl von Werten eines Bereichs) angeben kann.

id identification —Eine Kennzahl.

tmp, temp temporarily —Eine nur vorübergehen benötigte Hilfsvariable oder eine Variable für ein nur kurzzeitig benötigtes Objekt.

Abkürzungen*

Abkürzungen in Namen haben den Nachteil, daß man sich nicht nur des Namens erinnern muß, sondern auch der gewählten Art der Abkürzung. Als Abkürzung für „Programm“ ist beispielsweise "prog" oder "prg" oder auch "pgm" oder "prgm" möglich. Es fällt schwer, sich dann noch einzuprägen, welche  Abkürzung denn nun verwendet wurde, wenn man sich an anderer Stelle auf eine Abkürzung beziehen will, die man nicht vor Augen hat. Daher ist es meist besser, den vollständigen  Namen zu wählen, weil er sich leichter merken läßt.

Eine Ausnahme von dieser Regel sind standardisierte Abkürzungen, wie z.B. „MwSt“ für „Mehrwertsteuer“.

Partikel*

Partikel sind Namensteile, deren Bedeutung einer Spezifikation entnommen werden kann. Namen können dann aus Partikeln zusammengesetzt werden. Die Bedeutung eines Namens kann sich dann teilweise aus der Bedeutung der Partikel ergeben.

Wurde einmal festgelegt, daß das Partikel "giv" für einen gegebenen Zahlbetrag steht und das Partikel "eur" für „Euro“, dann ist es klar, daß "giveur" einen Zahlbetrag in Euro darstellt. Solche Partikel machen die Namen natürlich für „Nichteingeweihte“ schwer lesbar und empfehlen sich nur dann, wenn es gewährleistet ist, daß diese Partikel wirklich häufig und über einen längeren Zeitraum konsistent verwendet werden können. Beispielsweise, in einer Organisation, in der immer wieder Programme mit verschiedenen Beträgen und Währungen erstellt werden.