R für Dummies. Andrie de Vries
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 Code strukturieren
Namen sind nicht die einzigen Mittel, Ihren Code lesbarer zu machen. Wenn Sie erst anfangen, Funktionen zu verschachteln, oder komplexe Berechnungen anstellen, kann Ihr Code ziemlich schnell zu einem großen Ungetüm voller Text und Symbolen werden. Glücklicherweise kennen Sie ein paar Tricks, mit denen Sie Ihren Code lesbar gestalten – damit Sie auch in drei Monaten noch wissen, was Sie heute gemeint haben.
Funktionen verschachteln und komplexe Berechnungen anstellen, kann viele und lange Zeilen Quelltext entstehen lassen. Wenn Sie zum Beispiel einen Vektor mit Ihren drei Lieblingssongs erzeugen wollen, kann das schon umfangreich werden. Glücklicherweise dürfen Sie in R Zeilen an beliebiger Stelle umbrechen. So können Sie vermeiden, dass Sie den Cursor jedes Mal ganz nach rechts bewegen müssen, um die ganze Zeile zu lesen.
Beim Zeilenumbruch benötigt R keinen besonderen Hinweis. Es geht davon aus, dass die Anweisung noch nicht beendet ist, wenn Ihr Code darauf schließen lässt. Schreiben Sie also Code, bei dem kein Zweifel besteht, ob die Anweisung beendet ist oder nicht. Insbesondere können Sie Folgendes tun:
Sie können Anführungsstriche setzen, um den Beginn eines Texts zu kennzeichnen. R interpretiert alle nachfolgenden Zeichen, die Zeilenumbrüche eingeschlossen, als Teil des Texts – bis zum nächsten Anführungszeichen.