Lorsqu'on débute avec SAS© Viya™, il est fréquent de rencontrer différentes syntaxes pour effectuer une tâche apparemment identique : connecter une bibliothèque SAS© à une Caslib. Une confusion courante survient lors de l'initialisation d'une session et de l'assignation d'un libref.
Faut-il définir la Caslib uniquement dans les options de session (SESSOPTS) ou doit-on la spécifier à nouveau explicitement dans l'instruction LIBNAME ? Analysons les mécanismes sous-jacents pour démêler le fonctionnel des bonnes pratiques.
Considérons les deux extraits de code suivants, qui semblent accomplir la même action (charger la table sashelp.cars en mémoire) :
Approche A :
La différence réside dans la deuxième ligne. Dans l'approche B, l'option caslib=casuser est répétée dans l'instruction LIBNAME, alors qu'elle a déjà été définie juste avant dans l'instruction CAS (SESSOPTS). L'approche A est-elle incomplète ? L'approche B est-elle redondante ?
Pour répondre, il faut comprendre comment SAS© Viya™ gère le contexte de session :
Initialisation : Lorsque vous lancez une session CAS avec SESSOPTS=(caslib=casuser), vous définissez casuser comme la Caslib active.
Unicité : Il n'existe qu'une seule Caslib active à un instant donné dans une session.
Héritage par défaut : Si une instruction ultérieure nécessite une Caslib mais que vous ne la spécifiez pas, SAS© utilisera par défaut la Caslib active.
Par conséquent, l'approche A est techniquement correcte. L'instruction libname mycase cas; ne spécifiant pas de destination, le moteur CAS se rattache automatiquement à la Caslib active définie précédemment (ici casuser). Les deux codes sont donc fonctionnellement équivalents à l'instant T.
Si le code fonctionne sans répétition, pourquoi de nombreux experts et la documentation recommandent-ils l'approche B (spécification explicite) ?
Il y a deux raisons majeures :
1. La clarté et la lisibilité
Pour une personne relisant le code, l'instruction libname mycase cas caslib=casuser; est sans ambiguïté. Elle déclare explicitement la connexion entre le libref et la source de données, indépendamment de ce qui a pu être défini 50 lignes plus haut dans une option de session. C'est une déclaration d'intention claire.
2. Le verrouillage (Binding) et la sécurité
C'est l'argument technique le plus fort. Lier explicitement le libref à la Caslib empêche des comportements inattendus si le contexte change.
Imaginez que plus loin dans votre programme, la Caslib active soit modifiée (par exemple, via une nouvelle instruction CAS ou une option système).
Sans option explicite (Approche A) : Le moteur CAS étant dynamique, votre LIBNAME pourrait soudainement pointer vers la nouvelle Caslib active sans que vous ne vous en rendiez compte.
Avec option explicite (Approche B) : Le libref reste "verrouillé" (bound) à la Caslib casuser, peu importe les changements de Caslib active qui surviennent ensuite dans la session.
Bien que l'omission de l'option CASLIB dans l'instruction LIBNAME soit syntaxiquement permise grâce au mécanisme de "Caslib active", il est fortement recommandé de l'inclure systématiquement.
Cela rend votre code plus robuste face aux changements de contexte et plus lisible pour vos collaborateurs. En programmation SAS© Viya™ comme ailleurs, "explicite" est souvent préférable à "implicite".
