Esistono le "migliori pratiche" di codifica SAS?

Sono stato sul lato utente di alcuni sistemi SAS, e francamente la tua descrizione non mi sorprende un po '. Ho finito col fare un bel po 'di programmazione dei gap, per recuperare il gioco lasciato dalla squadra principale, che ha riferito che il codice SAS che avevano era difficile da modificare o eseguire il debug.

Considerati gli ostacoli che hai menzionato, le migliori pratiche derivano dal riconoscimento dei limiti del sistema e dall'applicazione di una separazione delle preoccupazioni a livello linguistico. In particolare:

1. Commenta prima, Code Second, Comment Last Se stai facendo OOP TDD, puoi saltare direttamente dentro e iniziare a codificare un prototipo, quindi lanciare i tuoi test e poi refactoring codice più pulito. Non puoi farlo in SAS. Decidi invece cosa vuoi che faccia il tuo codice PRIMA di scriverlo. Quindi scrivi il codice. Quindi torna indietro e modifica i tuoi commenti per assicurarti che siano accurati.

2. Abbraccia le funzionalità della lingua . Le macro sembrano un ottimo modo per condividere semplici blocchi di codice tra i programmi, sia come connessione a particolari sorgenti di dati, sia per eseguire funzioni distinte. Non buono come una chiamata di funzione corretta, ma meglio di niente.

3. Non fare in modo che SAS faccia ciò che le altre tecnologie possono fare meglio. Se stai inviando dati al server SQL e devi archiviare la tabella, lascia che sia SQL Server a gestirla. Se stai compilando i dati come opzioni per un programma sul lato client, invia le tue righe a un formato comune come XML e lascia che il programma lato client si preoccupi della sua segmentazione interna.

4. Non cercare di forzare un modello che SAS non supporta. Senza le classi, non puoi fare OOP, quindi non farlo. SAS è più vicino ad un insieme di script distinti o programmi mainframe di vecchia scuola comunque.

5. Semplice è meglio di complesso . I tuoi programmi SAS, se possibile, dovrebbero fare solo una cosa. Estrarre i dati dai sistemi client. Calcola le statistiche. Memorizza i dati calcolati. Formattare i dati calcolati come report. Ognuno di questi passaggi dovrebbe essere un file di programma SEPARATO, anche se devi forzarli in macro monouso per farlo.

6. Non essere intelligente . SAS è un agnostico, un meta-linguaggio che si estende da un poliglotta di origini dati ed esporta in una serie bizantina di formati. Che va tutto bene se è necessario accedere ad un formato oscuro o legacy, ma è solo un problema se si passa alle funzionalità interne di SAS senza, come minimo, lasciare spazio all'ottimizzazione dell'origine dati per produrre i dati più rapidamente .

7. Non essere tutto . SAS sembra uno strumento eccellente per l'aggregazione e l'analisi dei dati a livello aziendale. Ma le stesse caratteristiche che lo rendono così utile per renderlo orribile per qualcosa come un programma di posta elettronica, o un calcolatore personalizzato sul lato client.

Non ho lavorato direttamente con SAS, altrimenti ti darei specifiche migliori. Ma l'aggravante che SAS mi ha causato con quello che ho visto mi ha lasciato con una ferma opinione che SAS sia un linguaggio di nicchia e non dovrebbe essere usato al di fuori della sua nicchia. Non c'è niente di sbagliato nell'essere una lingua di nicchia - RegEx e XSLT sono entrambe lingue di nicchia, e sono due dei miei preferiti - ma è un odore di PHB quando a una squadra viene detto di "usare SAS" per ogni cosa.

È difficile rispondere in astratto, dal momento che SAS è un prodotto così enorme che potresti parlare di applicazioni GUI, routine ETL, applicazioni di modellazione del rischio e probabilmente altre cose a cui non sto pensando.

Detto questo, alcuni googling daranno risalto a questa classica carta da toungue-in-cheek: Programmazione per la sicurezza del lavoro rivisitata: ancora più suggerimenti e tecniche per massimizzare la tua indispensabilità (pdf).

Questo offre un'ottima guida su ciò che dovrebbe essere evitato.

Se le tue applicazioni sono ETL-ish, potresti dare un'occhiata a questo post sul blog che ho scritto un anno fa .

Sì, le migliori pratiche esistono e sono ampiamente conosciute dai professionisti. (Di cui io sono uno). Alcuni sono stati scritti da PHUSE sul loro wiki. link

Penso che in realtà SAS sia molto OO. Ma gli oggetti sono tabelle di dati. Contengono i metadati e possono essere manipolati. Per una visione più formale è possibile leggere "programmazione con dati" di Chambers per molti degli stessi obiettivi di progettazione e giustificazione per l'oggettivazione delle tabelle.

1 passaggio proc

SAS ha due parti - il livello elevato - specifico del dominio - procs per l'analisi e la maggior parte di ogni modello statistico. Questi hanno interfacce (sì, verbose). Ma buone impostazioni predefinite e facili da ottenere risposte. Ad esempio, prova a programmare anche un semplice ANOVA fattoriale in Fortran, C, C ++ o Java.

Passaggio 2 dati

E la seconda parte è un linguaggio di manipolazione dei dati di basso livello che precede l'SQL che è effettivamente sequenziale ma, molto veloce. Ha la proprietà che un programma che scrivi verrà eseguito su un set di dati di qualsiasi dimensione, limitato solo dallo spazio su disco o dal numero di nastri, se disponi di nastri. Questo differisce da tutte le lingue che ho menzionato e anche dalla maggior parte dei pacchetti di statistiche. (ad esempio R senza i pacchetti di file di grandi dimensioni aziendali da Revolution Analytics).

Il linguaggio macro si adatta a questo.

3 Tuttavia

I nuovi strumenti sono qui e questi sono l'oggetto hash che può persistere e il proc FCMP che può incapsulare passo dati di codice e passo proc. Può passare i valori o le matrici al chiamante. Vedi il mio articolo qui per ulteriori informazioni e riferimenti e una valutazione degli oggetti hash in un case study sulla vita reale.

link