Sas

SAS Language

<!-- SPDX-License-Identifier: MIT -->

<!-- Style rules derived from the @sasjs/core coding standards (https://github.com/sasjs/core), MIT licensed. -->

Write idiomatic, production-quality SAS code. This skill covers the SAS language itself, independent of any framework.

Scope

• DATA step programming (SET/MERGE/BY, RETAIN, arrays, DO loops, hash objects, first./last. processing)
• PROC SQL (joins, subqueries, views, pass-through with CONNECT TO)
• Macro language (%macro/%mend, macro variables, %local/%global, conditional %IF logic, quoting functions %STR/%NRSTR/%BQUOTE, CALL SYMPUTX)
• Common PROCs: SORT, MEANS/SUMMARY, FREQ, TRANSPOSE, REPORT, PRINT, CONTENTS, DATASETS, FORMAT, IMPORT/EXPORT
• Formats and informats (user-defined via PROC FORMAT, picture formats)
• ODS output (HTML, PDF, RTF, Excel, OUTPUT destination)
• File I/O: LIBNAME, FILENAME, INFILE/INPUT, FILE/PUT

Workflow

Apply this loop to every request that produces SAS code - new program, edit, or debug:

1. Analyze the request. Identify the input(s): datasets, columns, macro variables, platform (SAS 9 vs Viya). Note the desired output: a dataset, a report (ODS), a macro variable, a file. If the request is ambiguous, state your assumption and proceed.
2. Draft the code. Write the minimum correct program following the Style rules below. Use 2-level dataset names, explicit length for character variables, %local inside macros, and quit; for proc sql. Prefer proc sort nodupkey over hand-rolled dedup.
3. Run it (or describe the run). If a SAS session is available, submit and capture the log. If not, trace the code mentally against the Common pitfalls list - call out any step you could not verify.
4. Inspect the log. Treat any WARNING: or ERROR: as a defect to fix, not a note to ignore. Common culprits: uninitialized variables, implicit numeric->character conversion, truncation from implicit length=8, "no observations", unresolved macro references, read-only automatic macro variables. Superfluous NOTEs should also be trimmed where reasonable.
5. Review against pitfalls. Re-read the final code against the Common pitfalls list before returning it. Fix or annotate anything flagged.

Inputs: a request (natural language or a .sas file), optionally sample data or a log excerpt. Outputs: idiomatic SAS code (2-space indented, run;/quit; terminated) plus, when useful, a short note on any pitfall addressed or assumption made. Verification: the returned code passes a mental log-scan with zero WARNING/ERROR, and a real run (when available) produces a clean log.

Non-negotiable: no WARNINGs

Generated SAS code must run cleanly - zero WARNINGs (and zero ERRORs) in the log. Treat every WARNING: as a defect: uninitialized variables, implicit type conversions, truncation notes that should be warnings, "no observations", unresolved macro references, etc. If a warning is truly unavoidable, suppress it deliberately (e.g. an explicit option) and comment why. Likewise avoid superfluous NOTEs where reasonable.

Style rules

These follow the @sasjs/core coding standards - apply them to all SAS code:

• One statement per line; indentation = 2 spaces, no tabs, no trailing whitespace
• Consolidate multi-operand statements - %local/%global, length, attrib, retain, array, format/informat, label, keep/drop, var, rename - into a single statement listing all operands. Never split into duplicate statements (two %local lines, two length statements, etc.) just to stay under the line limit; if the line exceeds it, wrap to the next line - the statement ends at the semicolon, so continuation lines are free.
• Lines no longer than 80 characters; unix (LF) line endings; UTF-8
• Avoid non-ASCII / special characters entirely - maximum compatibility across SAS installations and encodings
• Always end steps with run;; for proc sql (and CAS-connected procs) quit; is essential to avoid WARNING: You cannot disconnect or terminate session ... on Viya
• All dataset references must be 2-level (work.blah, not blah) - protects against DATASTMTCHK=ALLKEYWORDS and an active USER library
• Explicit length / attrib for character variables rather than relying on defaults (avoids implicit length=8 truncation)
• Use literal suffixes for clarity ('01JAN2020'd, '12:30't)
• Prefer proc sort with nodupkey over manual dedup logic
• Macros:
  • Define with parentheses, even with no parameters: %macro x(); not %macro x;
  • Closing %mend; must repeat the macro name
  • Macro calls are not terminated with a semicolon: %my_macro() not %my_macro();
  • Mandatory parameters positional; optional parameters keyword (var=) style
  • Macro names lowercase, verb-noun convention
  • Macro variables without trailing dot (&var not &var.) unless needed to prevent incorrect resolution
  • Macro variable NAMES are case-insensitive: &Foo, &FOO, and &foo all resolve to the same symbol (same for %symexist/%superq/symget arguments, which take a NAME not a value). Don't chase case mismatches as a bug - it's never the cause.
  • ALL macro variables must be %local unless deliberately global (globals should use an application prefix to avoid collisions); use call symputx (not symput) in DATA steps
  • Comment with /* */ inside macros (asterisk comments are compiled into the macro)
  • Guard macro logic with %length(&var)=0 checks rather than &var= (empty comparisons are unsafe)
• Avoid naming collisions: use %sysfunc-/&syslast-based work tables (e.g. data &output; set &syslast; run;) rather than hard-coded names
• WORK library is auto-cleared on session termination: SAS deletes every table in WORK when the session ends, so explicit cleanup (proc datasets lib=work nolist; delete ...; quit;) is not required for ordinary temporary tables - do not add it, and do not flag its absence as a defect in review. Clean up explicitly only when temp files are large or voluminous enough to risk disk pressure mid-run; in that case, drop them as soon as they are no longer needed rather than leaving them for end-of-session disposal.
• No open (non-macro) conditional code: wrap platform-branching or conditionally-executed blocks (e.g. %if %mf_getplatform()=VIYA %then %do; ... %end;) in a %macro ... %mend and invoke the macro. Open %if at program level fails in some execution contexts (job/scheduler/test harnesses) and hides scope leaks.