Unterhaltsame Archäologie: Der Style Guide R unter der Lupe

Wie Sie wissen, wird Code viel häufiger gelesen als geschrieben. Damit zumindest jemand anderes als der Autor es lesen kann und es Styleguides gibt. Für R kann dies beispielsweise das Hadley-Handbuch sein.

Ein Styleguide ist nicht nur eine stillschweigende Vereinbarung zwischen Entwicklern - viele der Regeln haben einen merkwürdigen Hintergrund. Warum der Pfeil <- besser ist als das Gleichheitszeichen = , warum die Oldtimer von R den Unterstrich nicht mögen, wie die empfohlene Zeilenlänge mit der Lochkarte zusammenhängt und vieles mehr - mehr.

1. Zuweisungsoperator: <- vs =

In allen verfügbaren Handbüchern wird empfohlen, den nicht standardmäßigen Operator <- , jedoch nicht das Gleichheitszeichen = , das für andere moderne Sprachen üblich ist. Drei andere Operatoren ( <<- , -> , ->> ) werden nicht einmal erwähnt (wie der, der in früheren Versionen existierte := ). Es scheint, warum brauchen wir diesen nicht standardmäßigen Pfeil?

Die Geschichte enthüllt uns die Karten: In R kam der Pfeil von S, der ihn wiederum von der APL erbte. In APL konnten wir die Zuordnung von der Gleichheit unterscheiden. In R ist der Gleichheitsoperator Standard, daher ist der Unterschied unterschiedlich. Wenn der Pfeil ursprünglich ein Zuweisungsoperator war, hat das Gleichheitszeichen nur benannten Parametern Werte zugewiesen. Im Jahr 2001 wurde das Gleichheitszeichen zum Zuweisungsoperator, wurde jedoch nie zum Synonym für den Pfeil.

Was erlaubt es uns, = vollständigen Ersatz für den Pfeil in Betracht zu ziehen? Zunächst einmal = wie der Zuweisungsoperator nur auf der obersten Ebene arbeitet. Innerhalb der Funktion funktioniert beispielsweise alles wie zuvor:

 mean(x = 1:5) # [1] 3 x # Error: object 'x' not found mean (x <- 1:5) # [1] 3 x # [1] 1 2 3 4 5 

Hier = setzt nur den Funktionsparameter, während <- den Wert auch der Variablen x zuweist. Wir können den gleichen Effekt erzielen, indem wir die Zuweisungsoperation in Klammern setzen (nein, dies ist immer noch kein Lisp) :

 mean ((x = 1:5)) # [1] 3 x # [1] 1 2 3 4 5 

... oder in geschweiften Klammern:

 mean ({x = 1:5}) # [1] 3 x # [1] 1 2 3 4 5 

Außerdem hat der Pfeil Vorrang vor dem Gleichheitszeichen:

 x <- y <- 1 # OK x = y = 2 # OK x = y <- 3 # OK x <- y = 4 # Error in x <- y = 4 : could not find function "<-<-" 

Der letzte Ausdruck ist fehlgeschlagen, weil er (x <- y) = 4 , und der Parser interpretiert ihn als

 `<-<-`(x, y = 4, value = 4) 

Mit anderen Worten, wir versuchen, eine falsche Operation auszuführen: Weisen Sie zuerst x y und dann x und y 4 zu. Der Ausdruck wird nur dann fehlerfrei verarbeitet, wenn Sie die Priorität von Operationen in Klammern ändern: x <- (y = 4) .

2. Abstand

In der Anleitung wird empfohlen, Leerzeichen zwischen Operatoren zu setzen (außer natürlich eckige Klammern:, :: und :: :) sowie vor der öffnenden Klammer. Dies ist offensichtlich Teil der GNU-Codierungsstandards. Diese Klausel steht jedoch in engem Zusammenhang mit der Verwendung von <- als Zuweisungsoperator. Zum Beispiel

 x <-1 

Was ist das? X ist kleiner als -1? Oder x auf 1 setzen?

Der zusätzliche Platz ist jedoch nicht besser als der fehlende, zum Beispiel:

 x <- 0 ifelse(x <-1, T, F) # [1] TRUE x <- 0 ifelse(x < -1, T, F) # [1] FALSE 

Im ersten Fall steht zwischen < und - kein Leerzeichen, wodurch ein Zuweisungsoperator erstellt wird.

3. Namen von Funktionen und Variablen

Styleguides sind sich in der Frage der Namen nicht einig: Der Hadley-Guide empfiehlt Unterstriche für alle Namen; Google Guide - Trennung nach Punkten für Variablen und Kamelstil mit dem ersten Kleinbuchstaben für Funktionen; Bioconductor empfiehlt lowerCamel sowohl für Funktionen als auch für Variablen. In dieser Frage gibt es in der R-Community keine Einheit, und alle möglichen Stile können gefunden werden:

 lowerCamel period.separation lower_case_with_underscores allowercase UpperCamel 

Selbst für Basis-R-Namen gibt es keinen einheitlichen Stil (z. B. Rownamen und Zeilennamen sind unterschiedliche Funktionen!). Wenn Sie das unlesbare Allowercase nicht berücksichtigen (nur Matlab-Benutzer können es lieben), gibt es drei beliebteste Stile: Kleinbuchstaben, Kleinbuchstaben mit _ und Kleinbuchstaben mit Punkttrennung.



Die Beliebtheit verschiedener Stile für Funktionsnamen und Parameter (ein Name kann verschiedenen Stilen entsprechen). Quelle: Rasmus Bååth Performance on useR! 2017.


Die Punkt-zu-Punkt-Trennung erinnert bedrohlich an die Verwendung von Methoden in der objektorientierten Programmierung, ist jedoch historisch üblich. Es ist so üblich, dass dieser besondere Stil wirklich als R'vsky angesehen werden kann. Zum Beispiel verwenden die meisten Grundfunktionen es speziell (und jeder hat sich gerade mit data.table und as.factor getroffen).

Aber die Trennung ist einer der am wenigsten populären Stile (und hier geht Hadley gegen die Mehrheit). Für viele R-Benutzer sind Unterstriche ärgerlich: In der beliebten Emacs Speaks Statistics-Erweiterung wird sie standardmäßig durch den Zuweisungsoperator <- . Und die Standardeinstellungen ändert sich natürlich fast niemand.

Der Einfluss von Emacs ESS ist jedoch immer noch eine Erklärung aus der Kategorie "Schwanz wedelt mit dem Hund". Es gibt einen älteren Grund: In früheren Versionen von R war der Unterstrich gleichbedeutend mit dem Pfeil <- . Zum Beispiel könnten Sie im Jahr 2000 Folgendes treffen :

 #      R c <- c(1,2,3,4,5) mean(c) [1] 3 c_mean <- mean(c) c [1] 3 

Anstatt die Variable c_mean R hier den Wert 3 zuerst dem Variablenmittelwert und dann der Variablen c zugewiesen. In der modernen R werden solche Metamorphosen natürlich nicht auftreten.

Aufgrund der Unbeliebtheit finden sich _ Funktionen dieses Stils fast nicht unter den grundlegenden:

 #  3.5.1  25  grep("^[^\\.]*$", apropos("_"), value = T) 

Schließlich ist der LowerCamel-Stil bei Verwendung langer Namen schlecht lesbar:

 # ! GrossNationalIncomePerCapitaAtlasMethodCurrentUnitedStatesDollars 

In Bezug auf die Namen können Leitempfehlungen daher nicht als eindeutig angesehen werden. Immerhin ist dies eine Frage des Geschmacks (solange dies konsistent ist).

4. Geschweifte Klammern

Laut der Anleitung sollte eine neue Linie der öffnenden geschweiften Klammer folgen, und die schließende sollte sich auf einer separaten Linie befinden (sofern nicht anders gefolgt). Das heißt, ungefähr so:

 if (x >= 0) { log(x) } else { message("Not applicable!") } 

Alles hier ist nicht sehr interessant: Dies ist der Standard-Einrückungsstil von K & R, der auf die C-Sprache und das berühmte Buch von Kernigan und Ritchie „The C Programming Language“ (oder K & R mit den Namen der Autoren) zurückgeht.

Die Ursprünge dieses Stils liegen ebenfalls auf der Hand: Sie können Zeilen speichern und gleichzeitig die Lesbarkeit gewährleisten. Für frühe Computer war vertikaler Raum ein zu großer Luxus. Zum Beispiel wurde C auf PDP-11 entwickelt, in dessen Terminal sich nur 24 Leitungen befanden. Und beim Drucken eines K & R-Buches sparte dieser Stil Papier!

5. 80 Zeichenfolge

Die empfohlene Zeilenlänge gemäß Anleitung beträgt 80 Zeichen. Die magische Zahl 80 ist nicht nur in R zu finden, sondern auch in einer Vielzahl anderer Sprachen (Java, Perl, PHP usw. usw.). Und nicht nur Sprachen: Auch die Windows-Befehlszeile besteht aus 80 Zeichen.

Zum ersten Mal in der Programmierung erschien diese Nummer 1928 anstelle der Standard-IBM-Lochkarte, auf der genau 80 Datenspalten vorhanden waren. Eine viel interessantere Frage ist, warum ein solcher Standard gewählt wurde. Immerhin wurden zuvor Lochkarten unterschiedlicher Länge (für 24 oder 45 Spalten) verwendet.



Die beliebteste Antwort bezieht sich auf die Länge einer Lochkarte und die Zeilenlänge von Schreibmaschinen. Die ersten Maschinen wurden für das amerikanische Standardpapier 8½ x 11 Zoll entwickelt und konnten je nach Größe der Ränder zwischen 72 und 90 Zeichen drucken. Daher erscheint die Version von 80 Zeichen pro Zeile durchaus plausibel, obwohl dies im letzten Ausweg nicht der Fall ist. Es ist möglich, dass 80 Zeichen nur der Mittelweg in Bezug auf Ergonomie sind.

6. Zeileneinzug: Leerzeichen gegen Tabulatoren

Der von der Anleitung empfohlene Stil besteht aus zwei Leerzeichen und nicht aus einer Registerkarte. Die Ablehnung der Tabellierung ist durchaus verständlich: Die Länge der TAB variiert in verschiedenen Texteditoren (sie kann zwischen 2 und 8 Leerzeichen liegen). Wenn wir sie ablehnen, erhalten wir zwei Vorteile gleichzeitig: Erstens sieht der Code genauso aus, wie wir ihn eingegeben haben. Zweitens wird die empfohlene Zeichenfolgenlänge nicht versehentlich verletzt. In diesem Fall erhöhen wir natürlich die Dateigröße (wer möchte sich mit solchen Mikrooptimierungen in 2k19 befassen?)

Die Streiträume gegen Tabs haben eine lange Geschichte und können mit religiösen gleichgesetzt werden (wie Win gegen Linux, Android gegen iOS und dergleichen). Wir wissen jedoch bereits, wer es gewonnen hat: Laut der Stack Overflow- Studie verdienen Entwickler, die Leerzeichen verwenden, mehr als diejenigen, die Tabulatoren verwenden. Ein schlagkräftigeres Argument als die Regeln eines Styleguides, oder?

Anstelle einer Schlussfolgerung: Die Regeln der Styleguides mögen seltsam und unlogisch erscheinen. In der Tat, warum der Pfeil <- wenn es einen Standardoperator gibt = ? Aber wenn Sie tiefer graben, dann steckt hinter jeder Regel eine Logik, die oft schon vergessen ist.