Jaki jest Twój preferowany styl nazywania zmiennych w języku R? [Zamknięte]

Jakie konwencje nazewnictwa zmiennych i funkcji preferujesz w kodzie R?

O ile wiem, istnieje kilka różnych konwencji, z których wszystkie współistnieją w kakofonicznej harmonii:

1. Stosowanie separatora okresów, np

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

Plusy: Ma historyczną pierwszeństwo we wspólnocie R rozpowszechnionych w całym rdzeniu R, a zalecaną przez Google R Style Guide .

Wady: Rife z konotacjami zorientowanymi obiektowo i dezorientująca dla początkujących

2. Stosowanie podkreśleń

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

Zalety: wspólna konwencja w wielu językach programowania; ulubiony przez Hadley Wickham's Style Guide i używany w pakietach ggplot2 i plyr.

Wady: nie był historycznie używany przez programistów języka R; jest irytująco odwzorowany na operator '<-' w Emacs-Speaks-Statistics (zmienny za pomocą 'ess-toggle-underscore').

3. Stosowanie mieszanej wielkości liter (camelCase)

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

Zalety: wydaje się być szeroko stosowany w kilku społecznościach językowych.

Wady: ma niedawny precedens, ale nie był używany historycznie (ani w bazie R, ani w dokumentacji).

Na koniec, jakby to nie było wystarczająco zagmatwane, powinienem zwrócić uwagę, że Przewodnik po stylach Google przemawia za notacją kropkową dla zmiennych, ale mieszaną wielkością liter dla funkcji.

Brak spójnego stylu we wszystkich pakietach języka R jest problematyczny na kilku poziomach. Z punktu widzenia programisty utrudnia to utrzymywanie i rozszerzanie cudzego kodu (zwłaszcza gdy jego styl jest niezgodny z Twoim własnym). Z punktu widzenia użytkownika języka R niespójna składnia powoduje stromość krzywej uczenia się języka R, mnożąc sposoby wyrażania koncepcji (np. Czy funkcja rzutowania dat jest asDate (), as.date () lub as_date ()? Data()).

Dobre poprzednie odpowiedzi, więc tylko trochę do dodania tutaj:

• podkreślenia są naprawdę irytujące dla użytkowników ESS; biorąc pod uwagę, że ESS jest dość powszechnie używany, nie zobaczysz wielu podkreśleń w kodzie stworzonym przez użytkowników ESS (i ten zestaw zawiera kilka autorów R Core i CRAN, niezależnie od wyjątków takich jak Hadley);

• kropki też są złe, ponieważ można je pomylić w prostej metodzie wysyłki; Wydaje mi się, że kiedyś przeczytałem komentarze na ten temat dotyczące jednej z listy R: kropki są historycznym artefaktem i nie są już zalecane;

• więc mamy wyraźnego zwycięzcę w ostatniej rundzie: camelCase. Nie jestem też pewien, czy naprawdę zgadzam się ze stwierdzeniem „brak prekendentu w społeczności R”.

I tak: pragmatyzm i konsekwencja są ważniejsze od dogmatów. Więc cokolwiek działa i jest używane przez kolegów i współautorów. W końcu wciąż mamy spacje i nawiasy klamrowe, o które można się spierać :)

Zrobiłem ankietę na temat konwencji nazewnictwa, które są faktycznie używane w CRAN, które zostały zaakceptowane w R Journal :) Oto wykres podsumowujący wyniki:

Okazuje się (być może bez niespodzianek), że lowerCamelCase był najczęściej używany do nazw funkcji i kropek. Nazwy oddzielne były najczęściej używane jako parametry. Używanie UpperCamelCase, zgodnie z zaleceniami przewodnika Google po stylu R, jest jednak naprawdę rzadkie i jest trochę dziwne, że zalecają stosowanie tej konwencji nazewnictwa.

Pełny artykuł znajduje się tutaj:

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

Podkreślenia przez całą drogę! Wbrew powszechnej opinii w bazie R jest wiele funkcji, które używają podkreślenia. Biegnij, grep("^[^\\.]*$", apropos("_"), value = T)aby zobaczyć je wszystkie.

Używam oficjalnego stylu kodowania Hadley ;)

Lubię camelCase, gdy wielbłąd faktycznie dostarcza coś znaczącego - na przykład typ danych.

dfProfitLoss, gdzie df = dataframe

lub

vdfMergedFiles (), gdzie funkcja pobiera wektor i wypluwa ramkę danych

Chociaż myślę, że _ naprawdę zwiększa czytelność, po prostu wydaje się, że jest zbyt wiele problemów z używaniem.-_ Lub innych znaków w nazwach. Zwłaszcza jeśli pracujesz w kilku językach.

Sprowadza się to do osobistych preferencji, ale postępuję zgodnie z przewodnikiem stylu Google, ponieważ jest on zgodny ze stylem podstawowego zespołu. Nie widziałem jeszcze podkreślenia w zmiennej w bazie R.

Jak tu podkreślam:

Jak szczegółowość identyfikatorów wpływa na wydajność programisty?

warto pamiętać, jak zrozumiałe są twoje nazwy zmiennych dla współpracowników / użytkowników, jeśli nie są to native speakerzy ...

Z tego powodu powiedziałbym, że podkreślenia i kropki są lepsze niż wielkie litery, ale jak zauważyłeś, spójność jest niezbędna w twoim skrypcie.

Jak wspominali inni, podkreślenia zepsują wiele osób. Nie, to nie jest verboten, ale też nie jest szczególnie powszechne.

Używanie kropek jako separatora staje się trochę skomplikowane w przypadku klas S3 i tym podobnych.

Z mojego doświadczenia wynika, że ​​wiele brudnych śmieci w R woli używać camelCase, z pewną ilością kropek i odrobiną podkreślenia.

Zwykle zmieniam nazwy moich zmiennych, używając ix znaków podkreślenia i mieszanej wielkości liter (camelCase). Proste zmienne są nazywane za pomocą podkreśleń, na przykład:

PSOE_votes -> liczba głosów oddanych na PSOE (grupa polityczna Hiszpanii).

PSOE_states -> Categorical, wskazuje stan, w którym wygrywa PSOE {Aragon, Andalucia, ...)

PSOE_political_force -> Categorial, wskazuje pozycję między grupami politycznymi PSOE {pierwsza, druga, trzecia)

PSOE_07 -> Union of PSOE_votes + PSOE_states + PSOE_political_force w 2007 r. (H eader -> głosy, stany, stanowisko )

Jeśli moja zmienna jest wynikiem zastosowania funkcji w jednej / dwóch zmiennych, używam mieszanej wielkości liter.

Przykład:

positionXstates <- xtabs (~ stany + pozycja, PSOE_07)

Preferuję mieszane stolicę.

Ale często używam kropek, aby wskazać typ zmiennej:

mixedCapitals.mat to macierz. mixedCapitals.lm to model liniowy. mixedCapitals.lst jest obiektem listy.

i tak dalej.