SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
PL/I

PL/I static code analysis

Unique rules to find Bugs and Code Smells in your PL/I code

  • All rules 25
  • Bug1
  • Code Smell24
 
Tags
    Impact
      Clean code attribute
        1. "GO TO" statements should not be used

           Code Smell
        2. DFHRESP should be used to check EIBRESP values

           Code Smell
        3. "FIXED BIN" should be preferred to "INT"

           Code Smell
        4. "INONLY" or "NONASSIGNABLE" parameters should not be written to

           Code Smell
        5. Parentheses should be used in factored variable declarations

           Bug
        6. "END;" statements should have the same indentation level as their matching "PROCEDURE", "SELECT", and "DO" statements

           Code Smell
        7. The "DCL" abbreviation should not be used

           Code Smell
        8. Track parsing failures

           Code Smell
        9. Keywords should not be used as variable names

           Code Smell
        10. FIXED DECIMAL declarations should be defined with odd length

           Code Smell
        11. File names should comply with a naming convention

           Code Smell
        12. Variable names should comply with a naming convention

           Code Smell
        13. Procedure names should comply with a naming convention

           Code Smell
        14. String constants should not span multiple lines

           Code Smell
        15. Columns to be read with a "SELECT" statement should be clearly defined

           Code Smell
        16. Track breaches of an XPath rule

           Code Smell
        17. "if" statements should not be nested too deeply

           Code Smell
        18. "SELECT" statements should end with "OTHERWISE" statements

           Code Smell
        19. Track comments matching a regular expression

           Code Smell
        20. Statements should be on separate lines

           Code Smell
        21. "IF / ELSE" statements should use "DO ... END" structures

           Code Smell
        22. "STOP" statements should not be called

           Code Smell
        23. Comments should not be nested

           Code Smell
        24. Procedures should not have too many parameters

           Code Smell
        25. Lines should not be too long

           Code Smell

        "END;" statements should have the same indentation level as their matching "PROCEDURE", "SELECT", and "DO" statements

        Code Smell
        • convention

        Why is this an issue?

        For better readability, END statements must have the same indentation level as their matching opening PROCEDURE, SELECT, and DO statements.

        This rule does not verify the alignment of the compound statements DO ... END; (type 1) and BEGIN ... END;. They are mostly used together with the IF and ON statements and are subject to different indentation rules.

        Noncompliant code example

        foo: proc options(main);
          declare i fixed decimal init (0);
        
          do i = 0 to 9;
            if i = 0 then /* The do was forgotten here */
              put list ('Initialization...');
              put list ('i = 0');
              end; /* Non-Compliant - should be aligned with the DO statement */
          end; /* Non-Compliant - should be aligned with the PROCEDURE statement */
        
        /* The procedure's end seems to be missing */
        

        Compliant solution

        foo: proc options(main);
          declare i fixed decimal init (0);
        
          do i = 0 to 9;
            if i = 0 then do;
              put list ('Initialization...');
              put list ('i = 0');
            end; /* This end's alignment is not verified by this rule */
          end; /* Compliant */
        end; /* Compliant */
        
          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Enterprise
          Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use