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


110

Welche Konventionen zur Benennung von Variablen und Funktionen bevorzugen Sie im R-Code?

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

1. Verwendung eines Periodentrenners, z

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

Vorteile: Hat historische Vorrangstellung in der R-Community, die im gesamten R-Kern verbreitet ist und vom R Style Guide von Google empfohlen wird .

Nachteile: Reich an objektorientierten 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 gemeinsame Konvention in vielen Programmiergeschwindigkeiten; Von Hadley Wickhams Style Guide bevorzugt und in ggplot2- und plyr-Paketen verwendet.

Nachteile: Wird von R-Programmierern in der Vergangenheit nicht verwendet. ist in Emacs-Speaks-Statistics ärgerlicherweise dem Operator '<-' zugeordnet (änderbar mit 'ess-toggle-underscore').

3. Verwendung der gemischten Großschreibung (camelCase)

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

Vorteile: Scheint eine breite Akzeptanz in mehreren Sprachgemeinschaften zu haben.

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

Als ob es nicht verwirrend genug wäre, sollte ich schließlich darauf hinweisen, dass der Google Style Guide für die Punktnotation für Variablen, aber für die gemischte Großschreibung für Funktionen spricht.

Das Fehlen eines konsistenten Stils in allen R-Paketen ist auf mehreren Ebenen problematisch. Aus Entwicklersicht erschwert es das Verwalten und Erweitern des Codes anderer (insbesondere, wenn sein Stil nicht mit Ihrem eigenen übereinstimmt). Vom Standpunkt eines R-Benutzers aus steilert die inkonsistente Syntax die Lernkurve von R, indem sie die Art und Weise multipliziert, wie ein Konzept ausgedrückt werden kann (z. B. ist diese Datumsumwandlungsfunktion asDate (), as.date () oder as_date ()? Nein, es ist as. Datum()).


1
Es gibt auch Fälle von MATLAB Stil alllowercaseVariablennamen und viel gerade-aus-dem-Gleichung sehr kurzer Namen ( x, yusw.).
Richie Cotton

5
Unterstriche sind wie Python, daher verwende ich normalerweise Unterstriche. ESS sollte behoben werden, das ist wirklich dumm.
Brendan OConnor

7
Es gibt nichts zu reparieren, es gibt einen Schalter dafür. Das Standardverhalten besteht jedoch darin, einen Unterstrich als Verknüpfung zum <- Speichern einer Taste zum Drücken zu interpretieren. Wenn Sie also Variablen mit Unterstrichen veröffentlichen (Hi, Hadley), zwingen Sie jeden ESS-Benutzer, zweimal _ zu drücken, um das ursprüngliche Verhalten zu erhalten - oder sein ESS-Setup anzupassen. Ich bevorzuge camelCase immer noch mit neuen Seemeilen.
Dirk Eddelbuettel

2
camelCase hat auch Probleme, zB sind der Standard-Kamelkoffer ImfDataTransformedoder die natürliche erweiterte Version IMFDataTransformednicht so einfach zu lesen wie mein bevorzugter TOGGLEcamelCase: IMFdataTransformed...
PatrickT

1
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da die Antworten zwangsläufig meinungsbasiert sind.
Ben Bolker

Antworten:


81

Gute vorherige Antworten, also nur ein wenig, um sie hier hinzuzufügen:

  • Unterstriche sind für ESS-Benutzer sehr ärgerlich. Angesichts der Tatsache, dass ESS ziemlich weit verbreitet ist, werden Sie im Code, der von ESS-Benutzern verfasst wurde, nicht viele Unterstriche sehen (und dieser Satz enthält eine Reihe von R Core- und CRAN-Autoren, ungeachtet von Ausnahmen wie Hadley).

  • Punkte sind auch böse, weil sie beim einfachen Versand von 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 werden nicht mehr empfohlen;

  • Wir haben also noch einen klaren Sieger in der letzten Runde: camelCase. Ich bin mir auch nicht sicher, ob ich der Behauptung, dass es in der R-Gemeinschaft keinen Präzedenzfall gibt, wirklich zustimme.

Und ja: Pragmatismus und Beständigkeit trumpfen Dogma. Was auch immer funktioniert und von Kollegen und Co-Autoren verwendet wird. Immerhin haben wir noch Leerzeichen und Klammern, über die wir streiten müssen :)


6
+1 Gut gesagt! [Wenn nur das Kernteam einen endgültigen Styleguide herausgeben würde; Ich denke, das würde ihrer bereits implizierten Verwendung mehr Glaubwürdigkeit verleihen.]
Shane

1
Ich könnte mich aufgrund meiner eigenen Neigung zu gemischten Fällen nur falsch erinnern, aber ich glaube, das hat RG immer verwendet, wenn ich für ihn gearbeitet habe. Ich denke, was gut für RG ist, ist gut für mich!
Geoffjentry

Geoff: Keine schlechte Regel :)
Dirk Eddelbuettel

2
Danke für den Daumen hoch. Was das 'Dokument im kanonischen Stil' angeht: Mitmachen macht es nicht so, oder ich würde rosa Ponys reiten. Vielleicht können Sie damit beginnen, etwas zu verfassen, das Sie in das R-Wiki einfügen können, und wir alle bearbeiten, übernehmen und halten daran fest. Die Hoffnung ist ewig, wie sie sagen ...
Dirk Eddelbuettel

1
@Dirk - Ich habe vor, auf Ihre Empfehlung hin in Richtung Kamelhülle zu gehen, aber ich bin gespannt, ob Sie wissen, warum ?make.namesscheinbar durch Punkte getrennte Namen bevorzugt werden.
David LeBauer

73

Ich habe eine Umfrage durchgeführt, welche Namenskonventionen, die tatsächlich für CRAN verwendet werden und im R Journal akzeptiert wurden :) Hier ist eine Grafik, die die Ergebnisse zusammenfasst:

Geben Sie hier die Bildbeschreibung ein

Es stellt sich heraus (vielleicht keine Überraschungen), dass lowerCamelCase am häufigsten für Funktionsnamen und period.separated-Namen verwendet wurde, die am häufigsten für Parameter verwendet wurden. Verwendung von UpperCamelCase, wie im Google R Style Guide empfohlen ist jedoch sehr selten, und es ist etwas seltsam, dass sie die Verwendung dieser Namenskonvention befürworten.

Das vollständige Papier finden Sie hier:

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


2
Wie kommt es, dass die Prozentsätze nicht 100% betragen?
e9t

10
@ e9t Weil ein Name mit vielen Namenskonventionen übereinstimmen kann. printentspricht allen Konventionen außer UpperCamel und .OTHER_style.
Rasmus Bååth

Es wäre schön, dieses Papier zu aktualisieren.
Samuel-Rosa

34

Unterstrichen den ganzen Weg! Entgegen der landläufigen Meinung gibt es in Basis R eine Reihe von Funktionen, die Unterstriche verwenden. Laufgrep("^[^\\.]*$", apropos("_"), value = T) , um sie alle zu sehen.

Ich benutze den offiziellen Hadley- Codierungsstil;)


1
Das ist ordentlich! Die apropos- Funktion war mir vorher nicht bekannt . Dies gibt 10 Funktionen für mich in R 2.9.0 zurück; Ich würde kaum sagen, dass dies ein überzeugender Fall ist. Was ist Ihre Begründung für Unterstriche, wenn sie für R eindeutig in der Minderheit sind?
Shane

3
Nun, es ist 16 in R 2.10.0, das ist also eine Steigerung von 60% pro Version;) Ich mag sie hauptsächlich, weil sie mich an Ruby erinnern; camelCase erinnert mich an Java.
Hadley

6
Hadley, mein Herz sagt, dass ich Ihren Aufstand unterstützen soll, aber mein Kopf sagt, dass ich den Community-Standard respektieren und Ja zu camelCase sagen soll. :( Aber vielleicht ist Selbstkonsistenz alles, was zählt.
Medriscoll

5

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

dfProfitLoss, wobei df = Datenrahmen

oder

vdfMergedFiles (), wobei die Funktion einen Vektor aufnimmt und einen Datenrahmen ausspuckt

Während ich denke, dass _ die Lesbarkeit wirklich verbessert, scheint es einfach zu viele Probleme bei der Verwendung von.-_ Oder anderen Zeichen in Namen zu geben. Vor allem, wenn Sie in mehreren Sprachen arbeiten.


3

Dies hängt von den persönlichen Vorlieben ab, aber ich folge dem Google Style Guide, da er mit dem Stil des Kernteams übereinstimmt. Ich habe noch keinen Unterstrich in einer Variablen in Basis R gesehen.



2

Wie andere bereits erwähnt haben, werden Unterstriche viele Leute vermasseln. Nein, es ist nicht verboten, aber es ist auch nicht besonders häufig.

Die Verwendung von Punkten als Trennzeichen wird bei S3-Klassen und dergleichen etwas haarig.

Meiner Erfahrung nach bevorzugen viele der High Muckity Mucks von R die Verwendung von camelCase, mit etwas Punktverwendung und ein paar Unterstrichen.


1

Normalerweise benenne ich meine Variablen mit einem ix von Unterstrichen und einer gemischten Großschreibung (camelCase) um. Einfache Variablen benennen mit Unterstrichen, Beispiel:

PSOE_votes -> Anzahl der Stimmen für die PSOE (Fraktion Spaniens).

PSOE_states -> Categorical, gibt den Status an, in dem PSOE gewinnt {Aragon, Andalucia, ...)

PSOE_political_force -> Categorial, gibt die Position zwischen den Fraktionen der PSOE an (erste, zweite, dritte)

PSOE_07 -> Union von PSOE_votes + PSOE_states + PSOE_political_force bei 2007 (h eader -> Stimmen, Staaten, Position )

Wenn meine Variable das Ergebnis einer angewendeten Funktion in ein / zwei Variablen ist, verwende ich eine gemischte Großschreibung.

Beispiel:

positionXstates <- xtabs (~ Zustände + Position, PSOE_07)


0

Ich bevorzuge gemischte Hauptstädte.

Aber ich benutze oft Punkte, um anzugeben, was der Variablentyp ist:

mixCapitals.mat ist eine Matrix. mixCapitals.lm ist ein lineares Modell. mixCapitals.lst ist ein Listenobjekt.

und so weiter.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.