Built-in code review rules for EGL
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
ASexpressions 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
LIKEorMATCHESexpressions 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
NEWexpressions 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
COPYSTRorCOMPARESTRfunctions. 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
IFstatements that do not have a correspondingELSEblock. 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
IFstatements (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
SQLstatements that could potentially cause SQL to perform a sort on the result set. The rule is specifically looking for the keywords ofORDER BY,GROUP BY,JOIN, orUNIONto locate rule failures. - Avoid SQL statements without a result set id
- Use this rule to flag any
SQLstatements 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
TRYstatements that are coded without anONEXCEPTIONblock. 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.