Scrivere e organizzare bene il file di script aiuta a ritrovarsi con materiali ordinati e facilmente riutilizzabili. Poiché in R le convenzioni sono poche e abbastanza flessibili, è in fondamentale attenersi ad uno stile di coding in maniera coerente.

Leggibilità, manutenibilità e collaborazione. Innanzitutto, un file di codice ben scritto è comprensibile. Se il codice è disordinato e privo di commenti, tornando al lavoro dopo qualche settimana o mese, sarà difficile ricordare cosa si stava facendo e perché. Inoltre, in un file di script chiaro e ben strutturato è più facile individuare e correggere gli errori.

In questo senso, seguire le convenzioni (di R e/o della comunità disciplinare di riferimento) è fondamentale per la collaborazione per permettere ad altri di capire la logica e le intenzioni dietro le vostre scelte.

Replicabilità e riproducibilità. Più in generale, e ampliando la prospettiva, scrivere codice chiaro e ben documentato permette anche di riprodurre l'analisi con gli stessi dati (ottenendo gli stessi risultati), o di replicarla con altri dati, ad esempio per aggiornarla. Nella ricerca scientifica, la validità dei risultati può essere valutata in base alla loro riproducibilità, e molte riviste scientifiche richiedono la pubblicazione degli script di analisi insieme agli articoli.

Titolo e pacchetti all'inizio

Prima di tutto, è importante assegnare un titolo chiaro al proprio script, in modo da identificarlo rapidamente e comprenderne lo scopo. Lo si potrà inserire come commento, all’inizio.

Inoltre, sempre all'inizio, è considerata buona pratica elencare tutti i pacchetti necessari per eseguire il resto del codice codice. Questo permette di installarli, aggiornarli e caricarli, all'inizio, evitando interruzioni in seguito.

Va detto che RStudio, all'apertura dello script, avvisa l'utente nel caso in cui nel sistema non siano installati o non siano aggiornati i pacchetti necessari. Non tutti però usano RStudio, e, in ogni caso, l'indicazione iniziale dei pacchetti usati fornisce informazioni importanti sul percorso di analisi nel suo complesso.

Esempio:

# Titolo: Analisi dei dati di vendita
 
# Pacchetti
library(dplyr)
library(ggplot2)
library(readr)

Spesso, in pratica, questo significa rileggere lo script alla fine dell'analisi, e "trasportare" tutti i comandi relativi ai pacchetti all'inizio.

Nomi chiari e significativi.

Altra regola è quella di dare a variabili, funzioni o qualsiasi altro oggetto, nomi che abbiano un senso: dati_clienti è meglio di df1; calcola_totale è più chiaro di ct. Per le funzioni, spesso, si usano verbi o comunque espressioni che indicano quello che la funzione fa.

I commenti

In R, per indicare un commento, ovvero una riga di testo che non verrà eseguita, si utilizza il simbolo '#'.

I commenti fungono da note esplicative per chiarire cosa fa il codice, e/o perché si è fatta una determinata scelta. A volte, si usano i commenti anche per lasciare una nota per ricordare cosa manca o cosa richiede attenzione.

La regola generale è scrivere commenti chiari e concisi, che spieghino il cosa fa il codice e anche il perché.

# Calcolo della media dei voti
media_voti <- mean(voti)

Sezioni di codice

L'uso di commenti come #----- o #===== serve a creare sezioni visivamente distinte all'interno del codice. Possono essere di lunghezza variabile: RStudio, ad esempio crea separatori lunghi, ma possono andare bene anche pochi trattini.

Possono essere usate per dare un nome ai diversi “capitoli” del codice, ad esempio

# DATI ----

Indentazione.

In R, l'indentazione non è obbligatoria per il funzionamento del codice, ma resta fondamentale per la leggibilità. La convenzione più comune è usare 2 o 4 spazi per ogni livello di indentazione. L'importante è farlo, ed essere coerenti in tutto il codice.

In genere, gli editor con autocompletamento del testo indentano automaticamente, e permettono di scegliere gli spazi (nelle impostazioni).

# codice disordinato
if(x>10){print("Alto")}else{print("Basso")}

Questo frammento è certamente meno leggibile di quello successivo:

# codice ordinato
if (x > 10) {
  print("Alto")
} else {
  print("Basso")
}

Anche separare blocchi di codice con righe vuote può aiutare la leggibilità.

Spaziature.

Generalmente, si usano gli spazi prima e dopo gli operatori (x + y e non x+y) e dopo le virgole. Si evitano invece gli spazi all'interno delle parentesi o prima delle virgole ((x, y, z)).

Esempio:

# Spazi mancanti
media(x,y,z,na.rm=TRUE)
 
 
# Spazi corretti
media(x, y, z, na.rm = TRUE)

Lunghezza delle righe.

Anche qui non c'è una regola assoluta, ma si tende a mantenere la lunghezza delle righe di codice entro il limite degli 80 caratteri (e non oltre i 100-120). Righe troppo lunghe sono difficili da leggere e possono dare problemi di visualizzazione su schermi diversi.

Le righe andrebbero spezzate in un punto logicamente sensato, ad esempio prima di un operatore o dopo una virgola. L'indentazione indica che la riga continua.

Per delimitare le stringhe di caratteri (cioè, il testo), possono essere utilizzati sia gli apici singoli (') quanto le virgolette (“). Molte guide di stile (come quella del *Tidyverse*) raccomandano di usare i doppi apici (”) per coerenza, riservando gli apici singoli ai casi in cui la stringa stessa deve contenere doppi apici.

Per la definizione di una stringa semplice, infatti, essi sono generalmente intercambiabili:

stringa1 <- "testo"
stringa2 <- 'testo'
# stringa1 e stringa2 contengono lo stesso valore

La principale differenza pratica e il motivo per cui è consentito l'uso di entrambi è la possibilità di includere un tipo di apice all'interno di una stringa definita con l'altro tipo, senza dover usare caratteri di escape (la barra rovesciata \; vedi Vettori carattere):

# Apice singolo dentro doppi apici
"L'esempio è chiaro."
 
# Doppi apici dentro apici singoli
'Questo è un "esempio" importante.'
 
# Se si usano gli stessi apici, invece, serve l'escape (\)
"Questo è un \"esempio\" importante."
'L\'esempio è chiaro.'