Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarQube for IDE
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarQube Cloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube Server

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
GitHub Actions
Go
HTML
Java
JavaScript
JSON
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Rust
Scala
Shell
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML
YAML

RPG static code analysis

Unique rules to find Bugs, Security Hotspots, and Code Smells in your RPG code

Tags

Impact

Clean code attribute

"GOTO" statements should not be used
Code Smell
Delivering code in production with debug features activated is security-sensitive
Security Hotspot
Multiple occurrence data structures should not be used
Code Smell
Compile-time arrays should not be used
Code Smell
Optional operation codes should be omitted
Code Smell
"QUALIFIED" data structures should be used
Code Smell
Prototypes should be used
Code Smell
Comment lines should not be too long
Code Smell
"/COPY" statements should include specification letters
Code Smell
Standard language features should be in upper case
Code Smell
Subprocedures should be used instead of subroutines
Code Smell
Subprocedures should not reference global variables
Code Smell
"/EJECT" should be used after "F", "D" and "C" specification sections
Code Smell
"CONST" should be used for parameters that are not modified
Code Smell
Variables used in only one subprocedure should not be global
Code Smell
The "*srcstmt" header option should be used
Code Smell
Record formats should be cleared before each use
Bug
Two branches in a conditional structure should not have exactly the same implementation
Code Smell
Related "IF/ELSEIF" statements and "WHEN" clauses in a "SELECT" should not have the same condition
Bug
Unused subprocedures should be removed
Code Smell
Identical expressions should not be used on both sides of a binary operator
Bug
"IF" blocks should not have too many lines of code
Code Smell
"DO" blocks should not have too many lines of code
Code Smell
Variables should not be self-assigned
Bug
Non-input files should be accessed with the no lock option
Bug
The data area structure for "IN" should be defined in D spec lines.
Code Smell
"/COPY" should be avoided
Code Smell
SQL statements should not join too many tables
Code Smell
All opened "USROPN" files should be explicitly closed
Bug
The correct "ENDxx" statement should be used
Code Smell
Debugging statements "DEBUG(*YES)" and "DUMP" should not be used
Vulnerability
Line count data should be retrieved from the file information data structure
Bug
Track uses of disallowed operation codes
Code Smell
Indicators should be used on "CHAIN" statements
Code Smell
The first parameter of a "CHAIN/READx" statement should be a "KLIST"
Code Smell
The parameters of a "CALL" or "CALLB" statement should be defined as a "PLIST"
Code Smell
"IF" statements should not be conditioned on Indicators
Code Smell
LIKE keyword should be used to define work fields
Code Smell
Numeric fields should be defined as odd length packed fields
Code Smell
"E" should be found in F-spec lines
Code Smell
Error handling should be defined in F specs
Code Smell
Standard figurative constants *ON, *OFF and *BLANK should be used in place of '1', '0' and ' '
Code Smell
Unused subroutines should be removed
Code Smell
Subroutines should be documented
Code Smell
Subroutines should not be too complex
Code Smell
Columns to be read with a "SELECT" statement should be clearly defined
Code Smell
Track lack of copyright and license headers
Code Smell
Subroutines should not have too many lines of code
Code Smell
Control flow statements "IF", "FOR", "DO", ... should not be nested too deeply
Code Smell
"IF ... ELSEIF" constructs should end with "ELSE" clauses
Code Smell
Sections of code should not be commented out
Code Smell
String literals should not be duplicated
Code Smell
"SELECT WHEN" clauses should not have too many lines of code
Code Smell
Nested blocks of code should not be left empty
Code Smell
Unused variables should be removed
Code Smell
Expressions should not be too complex
Code Smell
Files should not have too many lines of code
Code Smell
Subroutine names should comply with a naming convention
Code Smell

Variables used in only one subprocedure should not be global

adaptability - modular

maintainability

Code Smell

pitfall

Why is this an issue?

Global variables that are only used by a single subprocedure should be declared in that subprocedure, thus limiting both their scope and other procedures' ability to modify the variable unexpectedly.

If the variable has been declared in the global scope to preserve its value between calls, add the STATIC keyword to the new local declaration. It will be added to the global heap and retained until the program ends, but only accessible by the subprocedure in which it was declared.

Noncompliant code example

     D SUBPROC1        PR
     D  Parm1                         5  0 Const

     D X               S              5  0    // Noncompliant; only used in one subproc

      /Free
       SUBPROC1(1234);
       *inlr = *on;
       return;
       /End-free

     P SUBPROC1        B
     D SUBPROC1        PI
     D  Parm1                         5  0 Const
      /Free
       X = Parm1 + 1;                        // X is only used here
       DSPLY(E) X;
      /End-Free
     P                 E

Compliant solution

     D SUBPROC1        PR
     D  Parm1                         5  0 Const

      /Free
       SUBPROC1(1234);
       *inlr = *on;
       return;
       /End-free

     P SUBPROC1        B
     D SUBPROC1        PI
     D  Parm1                         5  0 Const
     D X               S              5  0
      /Free
       X = Parm1 + 1;
       DSPLY(E) X;
      /End-Free
     P                 E

Available In:

Catch issues on the fly,
in your IDE

Analyze code in your
on-premise CI

Enterprise
Edition
Available Since
9.1

In-IDE

SaaS

Self-Hosted