Qual è il tuo stile preferito per denominare le variabili in R? [chiuso]

Quali convenzioni per la denominazione di variabili e funzioni preferisci nel codice R?

Per quanto ne so, ci sono diverse convenzioni differenti, che coesistono in cacofonica armonia:

1. Uso del separatore di periodo, ad es

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

Pro: ha la precedenza storica nella comunità R, prevalente in tutto il core R e consigliato dalla R Style Guide di Google .

Contro: Rife con connotazioni orientate agli oggetti e confuso per i neofiti R.

2. Uso di trattini bassi

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

Pro: una convenzione comune in molte lingue di programmazione; favorito dalla Style Guide di Hadley Wickham e utilizzato nei pacchetti ggplot2 e plyr.

Contro: non storicamente utilizzato dai programmatori R; è fastidiosamente mappato all'operatore '<-' in Emacs-Speaks-Statistics (modificabile con 'ess-toggle-underscore').

3. Uso di lettere maiuscole (camelCase)

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

Pro: sembra avere un'ampia adozione in diverse comunità linguistiche.

Contro: ha un precedente recente, ma non storicamente utilizzato (né nella base R né nella sua documentazione).

Infine, come se non fosse abbastanza confuso, devo sottolineare che la Guida allo stile di Google sostiene la notazione a punti per le variabili, ma l'uso di lettere maiuscole per le funzioni.

La mancanza di uno stile coerente tra i pacchetti R è problematica a diversi livelli. Dal punto di vista dello sviluppatore, rende difficile mantenere ed estendere il codice altrui (specialmente quando il suo stile non è coerente con il tuo). Dal punto di vista dell'utente R, la sintassi incoerente rende più accentuata la curva di apprendimento di R, moltiplicando i modi in cui un concetto potrebbe essere espresso (ad esempio, la funzione di casting della data è asDate (), as.date () o as_date ()? No, è come. Data()).

Buone risposte precedenti quindi solo un po 'da aggiungere qui:

• i trattini bassi sono davvero fastidiosi per gli utenti di ESS; dato che ESS è ampiamente utilizzato, non vedrai molti trattini bassi nel codice creato dagli utenti di ESS (e quel set include un gruppo di autori R Core e CRAN, nonostante le eccezioni come Hadley);

• anche i punti sono cattivi perché possono confondersi in un semplice metodo di spedizione; Credo di aver letto una volta commenti in tal senso su uno degli elenchi R: i punti sono un artefatto storico e non sono più incoraggiati;

• quindi abbiamo un chiaro vincitore ancora in piedi nell'ultimo round: camelCase. Inoltre, non sono sicuro di essere davvero d'accordo con l'affermazione di "mancanza di precendente nella comunità R".

E sì: pragmatismo e coerenza vincono il dogma. Quindi qualunque cosa funzioni e viene utilizzata da colleghi e coautori. Dopotutto, abbiamo ancora spazi bianchi e parentesi graffe su cui discutere :)

Ho fatto un sondaggio su quali convenzioni di denominazione sono effettivamente utilizzate su CRAN e che sono state accettate dal R Journal :) Ecco un grafico che riassume i risultati:

Risulta (senza sorprese forse) che lowerCamelCase è stato più spesso utilizzato per i nomi delle funzioni e period.separated nomi più spesso utilizzati per i parametri. Tuttavia, utilizzare UpperCamelCase, come sostenuto dalla guida di stile R di Google, è davvero raro ed è un po 'strano che sostengano l'utilizzo di quella convenzione di denominazione.

Il documento completo è qui:

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

Sottolineature fino in fondo! Contrariamente all'opinione popolare, ci sono un certo numero di funzioni in base R che usano trattini bassi. Corri grep("^[^\\.]*$", apropos("_"), value = T)a vederli tutti.

Uso lo stile di programmazione Hadley ufficiale ;)

Mi piace camelCase quando il cammello fornisce effettivamente qualcosa di significativo, come il tipo di dati.

dfProfitLoss, dove df = dataframe

o

vdfMergedFiles (), dove la funzione accetta un vettore e sputa un dataframe

Anche se penso che _ aggiunga davvero alla leggibilità, sembra che ci siano troppi problemi con l'uso di.-_ O altri caratteri nei nomi. Soprattutto se lavori in più lingue.

Questo dipende dalle preferenze personali, ma seguo la guida allo stile di Google perché è coerente con lo stile del team principale. Devo ancora vedere un trattino basso in una variabile in base R.

Come faccio notare qui:

In che modo la verbosità degli identificatori influisce sulle prestazioni di un programmatore?

vale la pena tenere a mente quanto siano comprensibili i nomi delle variabili per i tuoi colleghi / utenti se non sono madrelingua ...

Per questo motivo direi che i trattini bassi e i punti sono migliori delle maiuscole, ma come fai notare la coerenza è essenziale all'interno del tuo script.

Come altri hanno già detto, le sottolineature rovineranno molte persone. No, non è verboten ma non è nemmeno particolarmente comune.

Usare i punti come separatore diventa un po 'complicato con le classi S3 e simili.

Nella mia esperienza, sembra che molti dei muck ad alta muck di R preferiscano l'uso di camelCase, con alcuni punti e un'infarinatura di sottolineature.

Di solito rinomino le mie variabili usando una ix di trattini bassi e una maiuscola mista (camelCase). Le variabili semplici vengono denominate utilizzando trattini bassi, esempio:

PSOE_votes -> numero di voti per il PSOE (gruppo politico spagnolo).

PSOE_states -> Categorical, indica lo stato in cui vince il PSOE {Aragon, Andalucia, ...)

PSOE_political_force -> Categoriale, indica la posizione tra i gruppi politici del PSOE {primo, secondo, terzo)

PSOE_07 -> Union of PSOE_votes + PSOE_states + PSOE_political_force at 2007 (h eader -> votes, states, position )

Se la mia variabile è il risultato di una funzione applicata in una / due variabili, utilizzo una maiuscola mista.

Esempio:

positionXstates <- xtabs (~ states + position, PSOE_07)

Ho una preferenza per MixedCapitals.

Ma spesso uso i punti per indicare qual è il tipo di variabile:

mixedCapitals.mat è una matrice. mixedCapitals.lm è un modello lineare. mixedCapitals.lst è un oggetto elenco.

e così via.