Convenzioni, criteri e sfondo

Esistono molti modi per scrivere codice R per un determinato compito e ci sono ancora più modi per generare questo codice R da JS. Come farlo esattamente, è lasciato a voi. Ci sono ancora alcune considerazioni che si dovrebbero seguire e informazioni di base che si dovrebbero comprendere.

Comprendere l'ambiente local()

Molto spesso sarà necessario creare uno o più oggetti temporanei di R nel codice generato dalla propria estensione. Normalmente, non si desidera che vengano posizionati nell'area di lavoro dell'utente, potenzialmente anche sovrascrivendo le variabili utente. Quindi, tutto il codice generato dall'estensione viene eseguito in un ambiente local() (consultare la pagina della guida di R sulla funzione local()). Ciò significa che tutte le variabili create sono temporanee e non saranno salvate in modo permanente.

Se l'utente chiede esplicitamente il salvataggio di una variabile, sarà necessario assegnarla a quell'oggetto usando .GlobalEnv$objectname < - valore. In generale, non utilizzare l'operatore <<-. Non sarà assegnato necessariamente in .GlobalEnv.

Un errore importante è usare eval(). Notare che eval utilizzerà per impostazione predefinita l'ambiente attuale per la valutazione, cioè quello locale. Funzionerà bene la maggior parte delle volte, ma non sempre. Quindi, se si ha bisogno di usare eval(), probabilmente si vorrà specificare il parametro envir: eval(..., envir=globalenv()).

Formattazione del codice

La cosa più importante perché il proprio codice R generato funzioni, ma dovrebbe anche essere facile da leggere. Pertanto, fare attenzione anche alla formattazione. Alcune considerazioni:

Le istruzioni di primo livello di R dovrebbero essere allineate a sinistra.

Le istruzioni in un blocco inferiore devono essere rientrate con una tabulazione (vedere l'esempio seguente).

Se si eseguono calcoli molto complessi, aggiungere un commento ogni tanto, specialmente per contrassegnare sezioni logiche. Si noti che esiste una funzione dedicata comment() per l'inserimento di commenti traducibili nel codice generato.

Ad esempio, il codice generato potrebbe apparire così. Lo stesso codice senza rientri o commenti sarebbe piuttosto difficile da leggere, nonostante la sua modesta complessità:

# determina prima l'oscillazione e la rotazione
my.wobble <- wobble (x, y)
my.rotation <- wobble.rotation (my.wobble, z)

# il metodo preciso deve essere scelto in base alla rotazione
if (my.rotation > wobble.rotation.limit (x)) {
        method <- "foo"
        result <- boggle.foo (my.wobble, my.rotation)
} else {
        method <- "bar"
        result <- boggle.bar (my.wobble, my.rotation)
}
                

Gestire le operazioni complesse

Molte estensioni possono fare più di una cosa. Ad esempio, l'estensione «Statistiche descrittive» può calcolare media, intervallo, somma, prodotto, mediana, lunghezza, ecc. Tuttavia, in genere l'utente sceglierà di eseguire solo alcuni di questi calcoli. In questo caso, provare a mantenere il codice generato il più semplice possibile. Dovrebbe contenere solo parti rilevanti per le opzioni effettivamente selezionate. Per raggiungere questo obiettivo, ecco un esempio di un modello di progettazione comune come potrebbe essere utilizzato (in JS; qui, "domean", "domedian" e "dosd" sarebbero elementi <checkbox>):

function calculate () {
        echo ('x <- <' + getString ("x") + ')\n');
        echo ('results <- list ()\n');

        if (getBoolean ("domean.state")) echo ("results$" + i18n ("Mean value") + " <- mean (x)\n");
        if (getBoolean ("domedian.state")) echo ("results$" + i18n ("Median") + " <- median (x)\n");
        if (getBoolean ("dosd.state")) echo ("results$" + i18n ("Standard deviation") + " <- sd (x)\n");
        //...
}