Pli - CodeAnt AI

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

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.

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 */

INONLY or NONASSIGNABLE parameters should not be written to

Parameters that are declared as “INONLY” or “NONASSIGNABLE” are flagged as non-assignable by the compiler.

This rule raises an issue when a non-assignable parameter is written to.

sum: PROC(a, b);
dcl a fixed dec(15,2) NONASSIGNABLE;
dcl b fixed dec(15,2) NONASSIGNABLE;
a = a + b; /* Noncompliant */
return (a);
end;

Parentheses should be used in factored variable declarations

When multiple variables are DECLAREd in a single statement, parentheses must be used around the variable list to ensure the variable attributes in the statement are applied to all the variables in the declaration. Without parentheses, the attributes are applied only to the last variable in the list.

DECLARE X,Y FIXED BIN(15);

String constants should not span multiple lines

String literals written on multiple lines should not be used, especially since the new line characters are not part of the string anyway. The concatenation operator || should be used instead. Moreover, if trailing comments are present, they can be automatically removed by text editors and lead to unexpected results.

foo: proc options(main);
put list ('Hello,      /* Noncompliant; trailing space is not readable and may be stripped */
world');
end;

VALUE should be preferred to STATIC with INIT

Identifiers declared with `STATIC and INIT are initialized only once and may be later modified. Modifying such an identifier will fail at runtime when a CICS application is executed as reentrant. It is safer to declare the value as a named constant (using the keyword VALUE) because any modification will be reported at compilation time.

This rule raises an issue when an identifier is declared as STATIC with INIT or INITIAL` and has one of the following types:

CHARACTER/CHAR
BINARY/BIN
DECIMAL/DEC
FLOAT
POINTER/PTR
OFFSET

dcl returnCodeOk fixed bin(15) static init (00); /* Noncompliant */
/* or */
dcl actions char(05) init('12345') static; /* Noncompliant */
dcl actions_in char(01);
....
valid_action = (verify(action_in, actions) = 0);

Comments should not be nested

Defining a nested single-line comment within a multi-line comment invites errors. It may lead a developer to wrongly think that the lines located after the single-line comment are not part of the comment.

/*
This is a comment block, for which the ending tag was omitted
It may be difficult to figure out that the following line of code is actually commented


variable = function_call();
/* variable contains the result, this is not allowed, as it is an attempt to create an inner comment */

The DCL abbreviation should not be used

FIXED DECIMAL declarations should be defined with odd length

IF / ELSE statements should use DO ... END structures

While not technically incorrect, the omission of `DO … END can be misleading and may lead to the introduction of errors during maintenance.

In the following example, the two commands seem to be attached to the IF statement, but only the first one is, and put list (‘42!’)` will always be executed:

foo: proc options(main);
declare i fixed decimal init (0);

if i = 42 then
put list ('The answer is... '); /* Noncompliant */
put list ('42!');
end;

FIXED BIN should be preferred to INT

fixed bin(31) type has been optimized to run faster than int especially when used in loops. For this reason, fixed bin(31) should be preferred to int.

dcl i int(2) init (0);
do i = 1 to 20 by 1;
...
end;

Keywords should not be used as variable names

PL/I, unlike many other programming languages, does not reserve any word’s usage.

This implies that it is syntaxically valid to use the keyword IF as variable names for instance.

But doing so results in confusing code which is hard to read, especially in editors without proper PL/I syntax highlighting support.

foo: proc options(main);
declare if fixed decimal init (42); /* Non-Compliant */

if if = 42 then do; /* Cconfusing */
put list ('if = 42');
end;

go to goto; /* Confusing */

goto: /* Non-Compliant */
;
end;

DFHRESP should be used to check EIBRESP values

Whenever a CICS command is used with a `NOHANDE or RESP option, the default CICS exception handling is disabled. The correct approach then is to ensure that every possible exception is handled correctly directly in the code and to do this, you need to examine the RESP value or the EIBRESP field value.

It is possible to compare the RESP and EIBRESP field values to hard-coded numbers or variables containing numeric values; however, this makes the code difficult to read and maintain. It is recommended to use instead the DFHRESP built-in translator function, which enables the use of the equivalent symbolic values.

This rule raises an issue when the EIBRESP field is compared directly to a variable or hard-coded numeric value that is not wrapped in the DFHRESP function.

This rule does not handle RESP` values for now.

if EIBRESP=36 then /* Noncompliant */
end;

if EIBRESP=MAPFAIL then /* Noncompliant */
end;

select (EIBRESP);
when(36) ...;  /* Noncompliant */
end;

SELECT statements should end with OTHERWISE statements

If every WHEN test of a SELECT statement fails, an ERROR condition is raised if the OTHERWISE statement is omitted. This can lead to the unexpected termination of the program.

foo: proc options(main);
declare i fixed decimal init (42);

select (i); /* Non-Compliant - SELECT without OTHERWISE statement */
when (0) put list ('i = 0');
when (1) put list ('i = 1');
end;

put list ('Continuation'); /* This statement will not be executed */
end;

Statements should be on separate lines

Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.

Unresolved directive in <stdin> - include::{noncompliant}[]

Write one statement per line to improve readability.

Unresolved directive in <stdin> - include::{compliant}[]

foo: proc options(main);
declare i fixed decimal init(42); put list (i); /* Noncompliant - there are two statements */
end;

Variable names should comply with a naming convention

Sharing some naming conventions is a key point to make it possible for a team to efficiently collaborate. This rule allows to check that all variable names match a provided regular expression.

foo: proc options(main);
declare bar# fixed decimal; /* Noncompliant */
end;

GO TO statements should not be used

goto is an unstructured control flow statement. It makes code less readable and maintainable. Structured control flow statements such as if, for, while, continue or break should be used instead.

foo: proc options(main);
declare i fixed decimal init (0);

loopLabel:
put list (i);
i = i + 1;
if i < 10 then go to loopLabel;  /* Noncompliant - usage of the GO TO statement */
end;

Procedure names should comply with a naming convention

Shared coding conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.

foo#: proc options(main); /* Non-Compliant */
end;