Was ist Ihr bevorzugter Stil für die Benennung von Variablen in R?

Question

Welche Konventionen für die Benennung von Variablen und Funktionen bevorzugen Sie in R-Code?

Soweit ich das beurteilen kann, gibt es verschiedene Konventionen, die alle in kakophonischer Harmonie nebeneinander bestehen:

1. Verwendung des Punkttrennzeichens, z. B.

  stock.prices <- c(12.01, 10.12)
  col.names    <- c('symbol','price')

Vorteile: Hat einen historischen Präzedenzfall in der R-Gemeinschaft, ist im R-Kern weit verbreitet und wird von Google's R Style Guide .

Nachteile: Voller objektorientierter Konnotationen und verwirrend für R-Neulinge

2. Verwendung von Unterstrichen

  stock_prices <- c(12.01, 10.12)
  col_names    <- c('symbol','price')

Vorteile: Eine gängige Konvention in vielen Programmiersprachen; bevorzugt von Hadley Wickhams Style Guide und in den Paketen ggplot2 und plyr verwendet.

Nachteile: Wird von R-Programmierern historisch nicht verwendet; wird in Emacs-Speaks-Statistics ärgerlicherweise auf den Operator '<-' abgebildet (änderbar mit 'ess-toggle-underscore').

3. Verwendung von gemischter Großschreibung (camelCase)

  stockPrices <- c(12.01, 10.12)
  colNames    <- c('symbol','price')

Vorteile: Scheint in mehreren Sprachgemeinschaften weit verbreitet zu sein.

Nachteile: Hat einen aktuellen Präzedenzfall, wird aber nicht historisch verwendet (weder in der R-Base noch in der Dokumentation).

Als ob das nicht schon verwirrend genug wäre, sollte ich noch darauf hinweisen, dass der Google Style Guide für Variablen die Punktschreibweise, für Funktionen jedoch die gemischte Großschreibung empfiehlt.

Das Fehlen eines einheitlichen Stils in allen R-Paketen ist auf mehreren Ebenen problematisch. Vom Standpunkt eines Entwicklers aus betrachtet, macht es die Wartung und Erweiterung des Codes anderer schwierig (insbesondere wenn der Stil nicht mit dem eigenen übereinstimmt). Aus der Sicht eines R-Benutzers erhöht die inkonsistente Syntax die Lernkurve von R, da es mehrere Möglichkeiten gibt, ein Konzept auszudrücken (z.B. ist die Datums-Casting-Funktion asDate(), as.date() oder as_date()? Nein, es ist as.Date()).

Answer 1

Gute frühere Antworten, daher möchte ich hier nur etwas hinzufügen:

• Unterstriche sind realmente ärgerlich für ESS-Benutzer; da ESS ziemlich weit verbreitet ist, werden Sie nicht viele Unterstriche in Code sehen, der von ESS-Benutzern verfasst wurde (und diese Menge umfasst eine Reihe von R-Core- sowie CRAN-Autoren, von Ausnahmen wie Hadley einmal abgesehen);

• Punkte sind auch böse, weil sie in einfachen Methoden verwechselt werden können; ich glaube, ich habe einmal Kommentare zu diesem Effekt auf einer der R-Listen gelesen: Punkte sind ein historisches Artefakt und nicht mehr erwünscht;

• Wir haben also einen klaren Sieger in der letzten Runde: camelCase. Ich bin mir auch nicht sicher, ob ich wirklich mit der Behauptung übereinstimme, dass es in der R-Gemeinschaft keine Vorreiterrolle gibt.

Und ja: Pragmatismus und Konsistenz sind wichtiger als Dogmen. Was immer also funktioniert und von Kollegen und Mitverfassern verwendet wird. Immerhin haben wir noch Leerzeichen und geschweifte Klammern, über die wir uns streiten können :)

Answer 2

Ich habe eine Umfrage durchgeführt, welche Namenskonventionen auf CRAN tatsächlich verwendet werden, die im R Journal angenommen wurden :) Hier ist ein Diagramm, das die Ergebnisse zusammenfasst:

Es stellte sich heraus (vielleicht keine Überraschung), dass LowerCamelCase am häufigsten für Funktionsnamen und durch Punkte getrennte Namen am häufigsten für Parameter verwendet wurden. Die Verwendung von UpperCamelCase, wie sie von Google's R-Style Guide ist jedoch sehr selten, und es ist ein wenig seltsam, dass sie diese Namenskonvention befürworten.

Das vollständige Papier finden Sie hier:

http://journal.r-project.org/archive/2012-2/RJournal_2012-2_Baaaath.pdf

Answer 3

Unterstrichen wird alles! Entgegen der landläufigen Meinung gibt es in Base R eine Reihe von Funktionen, die Unterstriche verwenden. ausführen grep("^[^\\.]*$", apropos("_"), value = T) um sie alle zu sehen.

Ich verwende die offizielle Hadley-Stil der Codierung ;)

Answer 4

Ich mag camelCase, wenn das Kamel tatsächlich etwas Sinnvolles liefert - wie den Datentyp.

dfGewinnVerlust, wobei df = Datenrahmen

o

vdfMergedFiles(), wobei die Funktion einen Vektor entgegennimmt und einen Datenrahmen ausgibt

Ich denke zwar, dass _ wirklich zur Lesbarkeit beiträgt, aber es scheint einfach zu viele Probleme mit der Verwendung von .-_ oder anderen Zeichen in Namen zu geben. Vor allem, wenn man in mehreren Sprachen arbeitet.

Answer 5

Das ist eine Frage der persönlichen Vorliebe, aber ich folge dem Google Style Guide, weil er mit dem Stil des Kernteams übereinstimmt. Ich habe noch nie einen Unterstrich in einer Variable in Base R gesehen.