Skip to content

Linter

The information below is specific to the linter in the RPGLE extension.

Opening the linter config

Use vscode-rpgle.openLintConfig to open the rules configuration for the source you’re working in.

Open Lint Configuration command

Or you can right click on a library filter:

Open Lint Config with a click

If a linter rules file does not exist, you will be asked asked if you want to create one. The created file will provide some default rules, as below.

Relative lint config

  • If you are developing in source members (LIB/QRPGLESRC/MYSOURCE.RPGLE)
    • the the linter config exists in LIB/VSCODE/RPGLINT.JSON.
    • Each library has its own rules configuration file, binding it to all RPGLE sources in that library.
    • config changes get pickup when RPGLE sources are re-opened.
  • When developing in the IFS:
    • linter rules config exist in .vscode/rpglint.json relative to the current working directory.
    • config changes get pickup when RPGLE sources are re-opened.
  • When developing in a local workspace
    • linter rules exist in .vscode/rpglint.json relative to the workspace.
    • Local RPGLE gets scanned automatically when config is changed

Lint options

Below are some available lint configs. See the rpglint.json schema for the most up to date rules .

TypeRuleValueDescription
🌟indentnumberIndent for RPGLE.
🌟BlankStructNamesCheckbooleanStruct names cannot be blank (*N).
🌟QualifiedCheckbooleanStruct names must be qualified (QUALIFIED).
🌟PrototypeCheckbooleanPrototypes can only be defined with either EXT, EXTPGM or EXTPROC
🌟ForceOptionalParensbooleanExpressions must be surrounded by brackets.
🌟NoOCCURSbooleanOCCURS is not allowed.
πŸ€”NoSELECTAllboolean’SELECT *’ is not allowed in Embedded SQL.
🌟UselessOperationCheckbooleanRedundant operation codes (EVAL, CALLP) not allowed.
🌟UppercaseConstantsbooleanConstants must be in uppercase.
🌟IncorrectVariableCasebooleanVariable names must match the case of the definition.
🌟RequiresParameterbooleanParentheses must be used on a procedure call, even if it has no parameters.
🌟RequiresProcedureDescriptionbooleanProcedure titles and descriptions must be provided.
🌟StringLiteralDupebooleanDuplicate string literals are not allowed.
🌟RequireBlankSpecialboolean*BLANK must be used over empty string literals.
🌟CopybookDirectivestringForce which directive which must be used to include other source. (COPY or INCLUDE)
🌟DirectivesCasestringDirectives must be in the specified case. (lower or upper)
🌟UppercaseDirectivesbooleanDeprecated use DirectivesCase instead. Directives must be in uppercase.
πŸ€”NoSQLJoinsbooleanJOINs in Embedded SQL are not allowed.
🌟NoGlobalsInProceduresbooleanGlobals are not allowed in procedures.
🌟SpecificCasingarraySpecific casing for op codes, declartions or built-in functions codes.
🌟NoCTDATAbooleanCTDATA is not allowed.
🌟PrettyCommentsbooleanComments cannot be blank, must start with a space and have correct indentation.
🌟NoGlobalSubroutinesbooleanGlobal subroutines are not allowed.
🌟NoLocalSubroutinesbooleanSubroutines in procedures are not allowed.
🌟NoUnreferencedbooleanUnreferenced definitions are not allowed.
πŸ”’NoExternalTostring arrayCalls to certain APIs are not allowed. (EXTPROC / EXTPGM)
πŸ”’NoExecuteImmediatebooleanEmbedded SQL statement with EXECUTE IMMEDIATE not allowed.
πŸ”’NoExtProgramVariablebooleanDeclaring a prototype with EXTPGM and EXTPROC using a procedure is now allowed.
πŸ€”πŸŒŸIncludeMustBeRelativebooleanWhen using copy or include statements, path must be relative to the root. Usage is only recommended for local/workspace projects.
πŸ€”SQLHostVarCheckbooleanWarns when referencing variables in Embedded SQL that are also defined locally.
πŸ€”RequireOtherBlockbooleanRequires SELECT blocks to have an OTHER block.

Type key

KeyValue
🌟Clean code
πŸ€”Safe code
πŸ”’Secure code

SpecificCasing example

This rule allows you to specify the casing required for any or all declares or BIFs.

If you want all DCL to be lower case and all BIFs to be upper case, then it would be coded like this:

"SpecificCasing":[
{"operation": "*BIF","expected": "*upper"},
{"operation": "*DECLARE", "expected": "*lower"}
]

If you wanted %parms and %timestamp to always be lower case, and all other BIFs to be upper case, then it would be coded like this:

"SpecificCasing": [
{
"operation": "%parms",
"expected": "*lower"
},
{
"operation": "%timestamp",
"expected": "*lower"
},
{
"operation": "*bif",
"expected": "*upper"
}
]

Or, if for some reason, you wanted %timestamp to always be coded as %TimeStamp then it could be coded like this:

"SpecificCasing": [
{
"operation": "%parms",
"expected": "*lower"
},
{
"operation": "%timestamp",
"expected": "*TimeStamp"
},
{
"operation": "*bif",
"expected": "*upper"
}
]