The code review component supports built-in code review
rules for EGL.
These rules are built into the code review for EGL component
and do not require parameters. You can select these rules from the
Expressions, Specific Checks, Statements and Types categories in the
software analysis configuration window. For more information about
using this window, see Creating a software analysis configuration.
For information about exporting or importing a rule file, see Exporting and importing rules.
- Expressions:
- Avoid AS expressions
- Use this rule to flag any AS expressions in the
EGL source code. AS expressions are generally expensive to execute
in the CobolGen environment as they are associated with the ANY data
type, which requires CobolGen's usage of internal pseudo-objects.
- Avoid Like/Matches expressions
- Use this rule to flag any LIKE or MATCHES expressions
in the EGL source code. LIKE and MATCHES expressions are generally
expensive to execute in the CobolGen environment as they need to call
a complex runtime program.
- Avoid New expressions
- Use this rule to flag any NEW expressions in
the EGL source code. NEW expressions are generally expensive to execute
in the CobolGen environment as they are associated with the ANY data
type, which requires CobolGen's usage of internal pseudo-objects.
- Specific Checks:
- Avoid Copystr and Comparestr functions
- Use this rule to flag the invocations of COPYSTR or COMPARESTR functions.
These functions can be replaced with a more efficient sub-string assignment.
- Avoid direct assignment to Event Handler array
- Use this rule to flag direct assignments (=) to an event handler
array in an EGL Rich UI program. The proper technique is to append
to the array (::=).
- Avoid function parameters of type In
- Use this rule to flag any function parameter with a definition
type of IN. Although supported, when a parameter
is defined as type IN, it requires that the passed argument be copied
to a temporary variable.
- Avoid function parameters of type Out
- Use this rule to flag any function parameter with a definition
type of OUT. Although supported, when a parameter
is defined as type OUT, it requires that the passed argument be initialized
at the start of the function.
- Avoid having more than the specified number of parts in a source
file
- Use this rule to flag EGL source files that contain more than
a defined number of EGL parts (such as top-level functions and records).
You may override the default warning level of 50 parts, if you wish.
Placing too many parts in the same source file can have negative effects
on IDE build performance. It is better to break up the files into
many smaller ones.
- Avoid I/O statements without Try block
- Use this rule to flag I/O statements (such as Add, Get, Replace,
Delete, Open or Close) that are not immediately contained within a
try block.
- Avoid If without Else block
- Use this rule to flag IF statements that do not
have a corresponding ELSE block. Coding IF statements
without ELSE blocks can lead to logic paths where an error condition
is ignored.
- Avoid nesting If statements deeper than the specified number of
levels
- Use this rule to flag nested IF statements (IF
within another IF). You may override the default nesting level of
3, if you wish. If the nesting is more than specified number of levels
deep, then the rule flags the levels past the limit.
- Avoid number to text conversions
- Use this rule to flag any assignments where the source of the
assignment is of numeric type and the target of the assignment is
of text type. This usually involves an expensive formatting operation.
- Avoid recursive functions
- Use this rule to flag any functions that are involved with a series
of recursive invocations. This may involve several functions. The
recursive stack is displayed as part of the result, showing the recursive
path.
- Avoid SQL statements that cause a sort
- Use this rule to flag any SQL statements that
could potentially cause SQL to perform a sort on the result set. The
rule is specifically looking for the keywords of ORDER BY, GROUP
BY, JOIN, or UNION to locate
rule failures.
- Avoid SQL statements without a result set id
- Use this rule to flag any SQL statements that
could specify a result set id, but didn't. By not specifying result
set id in the statement, significant additional code will be generated
in a CobolGen environment, to allow the execution to dynamically determine
the result set to be used. This additional code can be eliminated
by specifying the correct result set id.
- Avoid text to number conversions
- Use this rule to flag any assignments where the source of the
assignment is of text type and the target of the assignment is of
numeric type. This usually involves an expensive operation to convert
the text to a valid number.
- Avoid Try statements without Onexception block
- Use this rule to flag any TRY statements that
are coded without an ONEXCEPTION block. Coding TRY
statements without ONEXCEPTION blocks can lead to logic paths where
an error condition is ignored.
- Require Dataitem usage
- Use this rule to flag any structured records that have embedded
fields that do not reference a Dataitem part as the field's type.
- Restrict Dataitem usage
- Use this rule to flag any structured records that have embedded
fields that reference a Dataitem part as the field's type.
- Validate for systems defined by part's build descriptor
- Use this rule to invoke an internal compile of the part being
processed by EGL Coding Rules to identify language features that are
not supported by the system type specified in the build descriptor
associated with the part.
- Statements:
- All EGL statements
- Select the desired EGL statement(s) to flag all statements of
the specified type.
- Types:
- All EGL data types
- Select the desired EGL data type(s) to flag all data types of
the specified type.