@sasjs/lint
Advanced tools
Our goal is to help SAS developers everywhere spend less time on code reviews, bug fixing and arguing about standards - and more time delivering extraordinary business value.
Note: The SASjs project and its repositories are not affiliated with SAS Institute.
@sasjs/lint is used by the following products:
sasjs lint to get a list of all files with their problems, along with line and column indexes.Configuration is via a .sasjslint file with the following structure (these are also the defaults if no .sasjslint file is found):
{
"hasDoxygenHeader": true,
"hasMacroNameInMend": true,
"hasMacroParentheses": true,
"hasRequiredMacroOptions": false,
"requiredMacroOptions": ["SECURE", "SRC"],
"ignoreList": ["sasjsbuild/", "sasjsresults/"],
"indentationMultiple": 2,
"lineEndings": "off",
"lowerCaseFileNames": true,
"maxDataLineLength": 80,
"maxHeaderLineLength": 80,
"maxLineLength": 80,
"noEncodedPasswords": true,
"noNestedMacros": true,
"noGremlins": true,
"noSpacesInFileNames": true,
"noTabs": true,
"noTrailingSpaces": true,
"defaultHeader": "/**{lineEnding} @file{lineEnding} @brief <Your brief here>{lineEnding} <h4> SAS Macros </h4>{lineEnding}**/"
}
Each setting can have three states:
false or 0. In this case, the rule won't be executed.For more details, and the default state, see the description of each rule below. It is also possible to change whether a rule returns ERROR or WARN using the severityLevels object.
Configuring a non-zero return code (ERROR) is helpful when running sasjs lint as part of a git pre-commit hook. An example is available here.
An array of hex codes that represents allowed gremlins (invisible / undesirable characters). To allow all gremlins, you can also set the noGremlins rule to false. The full gremlin list is here.
Example:
{
"noGremlins": true,
"allowedGremlins": ["0x0080", "0x3000"]
}
This isn't a rule, but a formatting setting, which applies to SAS program that do NOT begin with /**. It can be triggered by running sasjs lint fix in the SASjs CLI, or by hitting "save" when using the SASjs VS Code extension (with "formatOnSave" in place)
The default header is as follows:
/**
@file
@brief <Your brief here>
<h4> SAS Macros </h4>
**/
If creating a new value, use {lineEnding} instead of \n, eg as follows:
{
"defaultHeader": "/**{lineEnding} @file{lineEnding} @brief Our Company Brief{lineEnding}**/"
}
The SASjs framework recommends the use of Doxygen headers for describing all types of SAS program. This check will identify files where a doxygen header does not begin in the first line.
The addition of the macro name in the %mend statement is optional, but can approve readability in large programs. A discussion on this topic can be found here. The default setting was the result of a poll with over 300 votes.
As per the example here, macros defined without parentheses cause problems if that macro is ever extended (it's not possible to reliably extend that macro without potentially breaking some code that has used the macro). It's better to always define parentheses, even if they are not used. This check will also throw a warning if there are spaces between the macro name and the opening parenthesis.
This will require macros to have the options listed as "requiredMacroOptions." This is helpful if you want to ensure all macros are SECURE.
Example
{
"hasRequiredMacroOptions": true,
"requiredMacroOptions": ["SECURE", "SRC"]
}
There may be specific files (or folders) that are not good candidates for linting. Simply list them in this array and they will be ignored. In addition, any files in the project .gitignore file will also be ignored.
This will check each line to ensure that the count of leading spaces can be divided cleanly by this multiple.
This setting ensures the line endings in a file to conform the configured type. Possible values are lf, crlf and off (off means rule is set to be off). If the value is missing, null or undefined then the check would also be switched off (no default applied).
Example (to enforce unix line endings):
{
"lineEndings": "lf"
}
On *nix systems, it is imperative that autocall macros are in lowercase. When sharing code between windows and *nix systems, the difference in case sensitivity can also be a cause of lost developer time. For this reason, we recommend that sas filenames are always lowercase.
Datalines can be very wide, so to avoid the need to increase maxLineLength for the entire project, it is possible to raise the line length limit for the data records only. On a related note, as a developer, you should also be aware that code submitted in batch may have a default line length limit which is lower than you expect. See this usage note (and thanks to sasutils for reminding us).
This feature will work for the following statements:
The maxDataLineLength setting is always the higher of maxDataLineLength and maxLineLength (if you set a lower number, it is ignored).
See also:
In a program header it can be necessary to insert items such as URLs or markdown tables, that cannot be split over multiple lines. To avoid the need to increase maxLineLength for the entire project, it is possible to raise the line length limit for the header section only.
The maxHeaderLineLength setting is always the higher of maxHeaderLineLength and maxLineLength (if you set a lower number, it is ignored).
See also:
Code becomes far more readable when line lengths are short. The most compelling reason for short line lengths is to avoid the need to scroll when performing a side-by-side 'compare' between two files (eg as part of a GIT feature branch review). A longer discussion on optimal code line length can be found here
In batch mode, long SAS code lines may also be truncated, causing hard-to-detect errors.
We strongly recommend a line length limit, and set the bar at 80. To turn this feature off, set the value to 0.
See also:
This rule will highlight any rows that contain a {sas00X} type password, or {sasenc}. These passwords (especially 001 and 002) are NOT secure, and should NEVER be pushed to source control or saved to the filesystem without special permissions applied.
Capture zero-width whitespace and other non-standard characters. The logic is borrowed from the VSCode Gremlins Extension - if you are looking for more advanced gremlin zapping capabilities, we highly recommend to use their extension instead.
The list of characters can be found in this file: https://github.com/sasjs/lint/blob/main/src/utils/gremlinCharacters.ts
Where macros are defined inside other macros, they are recompiled every time the outer macro is invoked. Hence, it is widely considered inefficient, and bad practice, to nest macro definitions.
The 'beef' we have with spaces in filenames is twofold:
In addition, when such files are used in URLs, they are often padded with a messy "%20" type quotation. And of course, for macros (where the macro should match the filename) then spaces are simply not valid.
As an alternative (or in addition) to using a lint rule, you can also set the following in your .gitignore file to prevent files with spaces from being committed:
# prevent files/folders with spaces
**\ **
Whilst there are some arguments for using tabs (such as the ability to set your own indentation width, and to reduce character count) there are many, many, many developers who think otherwise. We're in that camp. Sorry (not sorry).
This will highlight lines with trailing spaces. Trailing spaces serve no useful purpose in a SAS program.
This setting allows the default severity to be adjusted. This is helpful when running the lint in a pipeline or git hook. Simply list the rules you would like to adjust along with the desired setting ("warn" or "error"), eg as follows:
{
"noTrailingSpaces": true,
"hasDoxygenHeader": true,
"maxLineLength": 100,
"severityLevel": {
"hasDoxygenHeader": "warn",
"maxLineLength": "error",
"noTrailingSpaces": "error"
}
}
A formatter will automatically apply rules when you hit SAVE, which can save a LOT of time.
We've already implemented the following rules:
We're looking to implement the following rules:
We are also investigating some harder stuff, such as automatic indentation and code layout
SASjs is an open source framework! Contributions are welcomed. If you would like to see a feature, because it would be useful in your project, but you don't have the requisite (Typescript) experience - then how about you engage us on a short project and we build it for you?
Contact Allan Bowe for further details.
Thanks goes to these wonderful people (emoji key):
 Carus Kyle 🤔 |  Allan Bowe 💻 ⚠️ 👀 📹 📖 |  Yury Shkoda 💻 ⚠️ 📆 📹 📖 |  Krishna Acondy 💻 ⚠️ 👀 🚇 📦 🚧 🖋 |  Muhammad Saad 💻 ⚠️ 👀 🧑🏫 📖 |  Sabir Hassan 💻 ⚠️ 👀 🤔 |  Mihajlo Medjedovic 💻 ⚠️ 👀 🚇 |
 Vladislav Parhomchik ⚠️ 👀 |  McGwire-Jones 💻 |
This project follows the all-contributors specification. Contributions of any kind welcome!
FAQs
Linting and formatting for SAS code
We found that @sasjs/lint demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 3 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Axios compromise traced to social engineering, showing how attacks on maintainers can bypass controls and expose the broader software supply chain.
Security News
Node.js has paused its bug bounty program after funding ended, removing payouts for vulnerability reports but keeping its security process unchanged.
Security News
The Axios compromise shows how time-dependent dependency resolution makes exposure harder to detect and contain.