Naming rules:
For the following objects you may provide a regular
expression defining correct names.
Abstract SubProgram Name.
Generic Declaration Name.
Generic Instantiation Name.
Number Name.
Object Name.
Package Name.
Exception Renaming Name.
Generic Renaming Name.
Object Renaming Name.
Package Renaming Name.
SubProgram Renaming Name.
Single Protected Name.
Single task Name.
Function Name.
Procedure Name.
SubType Name.
Full Type Name.
Protected Type Name.
Task Type Name.
Incomplete Type Name.
Private Extension Name.
Private Type Name.
Pragma Name.
Parameter Name.
Loops:
Loop and block statements must bear a name (identifier)
referring to the purpose of the loop or block.
Exit statement is only allowed in loop having a loop
or while iteration scheme.
An exit statement may not mention a loop name.
A block statement may only be introduced once local
declarations or exception handling are needed.
Routine parameters and Routine usages:
The mode of the parameters in a procedure formal part must
be explicit and must refer to the logical usage of them.
A subprogram can only deliver values through its out/in out
parameters (in the case of a procedure) or through its
returned value (in the case of a function).
All parameters declared, as out must be assigned inside the
procedure before returning.
May replace procedure with function.
Function result type may not be unconstrained.
Do not use return in procedure.
In a procedure call two distinct formal in out and/or out
parameters may not be associated with the same actual
parameter.
Named associations are to be used for parameter association.
Types:
Except for (limited) private types, the identifiers of
objects declared with an access type will end with _PTR.
No usage of anonymous types is allowed.
No default expression is allowed in a discriminant
specification.
The full type declaration corresponding to a (non limited)
private type declaration may not be an access type
declaration.
The subtype indication in an access type definition may not
denote an unconstrained array or record type.
No dynamic subtype indications.
Tasks:
No task type specification is allowed.
No task object may be declared.
Exceptions:
The last statement of an exception handler must always be a raise
statement raising the exception PROGRAM_ERROR. For PROGRAM_ERROR
no handler is allowed in the system.
Pragmas:
The pragma SUPPRESS may only be used with the ON clause.
Each usage of this pragma has to be justified by a comment.
A pragma SUPPRESS may never deactivate ELABORATION_CHECK.
Each real type must be checked with MACHINE_OVERFLOWS.
UNCHECKED_DEALLOCATION will not be used.
UNCHECKED_CONVERSION will not be used.
Threshold based rules:
Routine Statement Count treshold exceeded.
Routine Cyclomatic Complexity treshold exceeded.
Routine Max Nesting treshold exceeded.
Routine Line Count treshold exceeded.
Package Type Count treshold exceeded.
Package Routine Count treshold exceeded.
Module Line Count treshold exceeded.
Module Comment Ratio treshold exceeded.
Misc:
A package specification, a package body and a subprogram body
must be closed by its (simple_)name (identifier).
Underline characters are to be used in numeric literal to
separate the thousands.
The usage of the goto statement is prohibited.
Space Around Operator.
A case statement based on an enumeration type may not include
choices based on ranges or others.
Unicity imposes the presence of only one declaration/instruction
per line in a declarative_part/sequence_of_statements.
No generic unit may be embedded in a generic unit.
The declarative part of a subprogram may not contain a package
as declarative item.
Enumeration Representation Clauses are not allowed.
March 2008: RainCode proudly releases a complete Datacom migration
solution
named
DataKom
which covers all aspects of Datacom migration: CA-IDEAL,
COBOL programs and data migration.
September 2007: The
RainCode Checker for COBOL
computes the
size and offsets
of
data elements according to the ANSI standard, and can be used to find and
analyze data elements based on how and where they are represented physically
in memory.
January 2007: The
RainCode Checker for COBOL
is released, with over 70 coding guidelines
built-in. The RainCode Checker can be used to check
large portfolios
against project-wide or company-wide coding guidelines.
June 2006: The various versions of the
RainCode engine now
provides access to
native lexical information from within scripts, so that
coding guidelines related to the position of keywords, alignements, etc.
can be coded much more efficiently than before.
February 2005:
RainCode decides to distribute the RainCode Engine for Ada, C,
and COBOL
for FREE.
Get your own license on
RainCode Online.