ist ziemlich liberal bei der Benennung von Objekten und Funktionen. Dies ist Fluch und Segen zugleich. Niemand muss festen Regeln folgen. Wenn also jemand etwas programmiert, kann er das im Wesentlichen nach Belieben tun .
Einen zulässigen Namen wählen
Obwohl fast alles in R erlaubt ist, gibt es dennoch ein paar Regeln, die Sie bei der Vergabe von Namen für Objekte nicht umgehen können.
Namen fangen mit einem Buchstaben oder einem Punkt an. Wenn sie mit einem Punkt anfangen, darf an zweiter Stelle keine Ziffer stehen.
Namen sollten ausschließlich aus Buchstaben, Zahlen, Unterstrichen (_) und Punkten (.) bestehen. Obwohl Sie R zwingen können, auch andere Zeichen zu akzeptieren, könnte das unangenehme Folgen haben. Andere Zeichen haben nämlich häufig eine spezielle Bedeutung in R.
Folgende Schlüsselwörter sind als Namen verboten:breakelseFALSEforfunctionifInfNANaNNextNULLrepeatreturnTRUEwhile
nachname und Nachname unterschiedliche Objekte. Es kann vorkommen, dass R ein Objekt nicht findet, obwohl Sie Stein und Bein schwören, es erzeugt zu haben. In so einem Fall ist die Erinnerung an Groß-/Kleinschreibung Gold wert.
Einen klaren Namen wählen
Wenn Sie programmieren, dann sind Sie vermutlich immer versucht, kurze, generische Namen wie x oder y zu verwenden. Daran ist prinzipiell nichts auszusetzen, allerdings sollte immer klar sein, wofür der Name selbst steht. Das kann gerade bei größeren Projekten oder Projekten, die Sie nach längerer Zeit beispielsweise erweitern wollen, schnell zu Verwirrung führen. Genauso kann es anderen Leuten die Lesbarkeit Ihres Codes erheblich erschweren, wenn Sie Ihre Datensätze nur mit data1, data2 und so weiter bezeichnen, ganz gleich, ob es für Sie selbst in dem Moment, als Sie Ihr R-Programm geschrieben haben, Sinn ergeben hat. Denken Sie immer daran: Sie könnten derjenige sein, der in drei Monaten rausfinden muss, was mit x oder data1 gemeint war! Beschreibende Namen sind da eine große Hilfe.
Obwohl Sie Ihre Objekte nennen können, wie Sie wollen, sind doch manche Namen weniger verwirrend als andere. Zum Beispiel ist Ihnen womöglich aufgefallen, dass keine der bisher verwendeten Funktionen auf der Liste der verbotenen Namen etwas weiter oben auftaucht. Das können Sie wörtlich nehmen: Wollen Sie Ihr Objekt paste nennen? Bitte sehr:
> paste <- paste("Das ist ja ", "verwirrend!")
> paste
[1] "Das ist ja verwirrend!"
> paste("Finden","Sie nicht?")
[1] "Finden Sie nicht?"
Für R ist es kein Problem, herauszufinden, ob Sie gerade Ihren Vektor paste oder die Funktion paste() aufrufen wollen. Jedoch ist es möglicherweise keine gute Idee, diesen Namen zu vergeben. Obwohl es also streng genommen nicht verboten ist, vergeben Sie am besten nie Funktionsnamen für Ihre Variablen.
F oder T als Objektname vergeben. Es geht, aber sehr wahrscheinlich werden Sie damit Schiffbruch erleiden. Obwohl es schlechter Stil ist, werden häufig F und T als Abkürzungen für FALSE und TRUE verwendet, das versteht R auch. Gleichzeitig sind F und T keine reservierten Wörter. R sucht zunächst nach Objekten dieses Namens, und erst, wenn das nicht klappt, löst es die Abkürzung mit FALSE oder TRUE auf. Wenn Sie jetzt Code haben, der erwartet, dass T auch wirklich TRUE bedeutet, könnte es eng werden. Erschwerend kommt hinzu, dass R Ihnen davon möglicherweise noch nicht einmal etwas mitteilt. Der Code kann durchaus noch zulässig sein. Er tut jedoch nicht mehr, was Sie erwarten. Um auf der sicheren Seite zu sein, nutzen Sie also weder die Abkürzungen F und T noch verwenden sie als Namen für Objekte.
Die Struktur für Namen wählen
Wenn Sie bereits Erfahrung mit Programmierung haben, kennen Sie vielleicht die camelCase-Notation (im Deutschen korrekt, jedoch etwas weniger anschaulich: Binnenversalien). Mit ihr kann man längere Objektnamen strukturieren. Indem Sie jedes neue Wort im Namen mit einem Großbuchstaben anfangen lassen, erleichtern Sie das Lesen. So lässt sich auch ein superLangerVariablenName auf einen Blick leicht erfassen.
Alternativ können Sie auch super.langer.variablen.name schreiben. Das ist in R möglich, weil R den Punktoperator (.) nicht kennt. Dies nennt man dotted style (von englisch dot = Punkt). R benutzt selbst den dotted style für viele Funktionsnamen. Ein solcher Name ist uns bereits in diesem Kapitel begegnet: print.default(). In manchen Paketen begegnet Ihnen auch ein Unterstrich anstelle des Punkts.
print.default() ist die Standardmethode für die Funktion print(). Informationen zu den Argumenten von print() finden Sie auf der Hilfeseite von print.default().
Natürlich müssen Sie nicht den dotted style verwenden. Wir benutzen in diesem Buch camelCase für Funktionen und dotted style für alle anderen Objekte. Zwar nutzt R für viele Basisfunktionen und andere Objekte dotted style, jedoch wird der Punkt intern auch für andere Zwecke verwendet. Aus diesem Grund halten wir es für sicherer, für Funktionen camelCase zu verwenden. Wenn Sie jedoch im Code irgendwo einen Punkt sehen: Keine Angst, der tut nichts. Er ist nur Teil des Namens.
Das ganze Thema mit den Namen ist einer der Nachteile von quelloffener Software. Sie wird von sehr schlauen und altruistischen Personen geschrieben, die manchmal sehr starke Überzeugungen haben. Die führen dazu, dass die Namenskonventionen alles andere als standardisiert sind.
Konsequent inkonsequent
Eigentlich würde man einen Funktionsnamen wie save.history() erwarten, die Funktion heißt aber savehistory (). Ähnlich gelagert ist der Fall mit R.Version(). Hier würde man eher R.version() erwarten. Die Funktion R.Version() gibt Ihnen alle möglichen Informationen über die gerade verwendete Version von R sowie das System, auf dem sie läuft. In anderen Fällen finden Sie lupenreine camelCase-Notation. Wenn Sie zum Beispiel nur an der Versionsnummer von R interessiert sind, fragen Sie diese mit der Funktion getRversion() ab. Manche Autoren von Paketen benutzen lieber Unterstriche (_) zur Trennung der Wörter. Dies wird uns noch weiter hinten im Buch begegnen, zum Beispiel im Paket ggplot2, das wir Ihnen in Kapitel 18 vorstellen.
Den
