Code Quality

The code quality tool can enforce coding conventions, detect potential errors, detect deprecated syntax, and provide guidance during code development or migration.

Introduction: Why a Code Quality tool?

The tool's purpose is to ensure that coding conventions and standards are being followed by the application developers. By using the tool, coding conventions can be verified by the developers during the build process before committing code changes. The lint rules file defines the rules governing code quality, and the tool can be activated or deactivated by setting the GSLINTENABLED environment variable.

The gslint application focuses on Genero BDL code, however additional rules could be checked by third-party tools. For example, rules could be added to validate text file formatting, such as the use of tabs versus spaces, or the proper CR/LF format.

The gslint tool can be run from the command line.

The lint rules file

The rules governing code quality is defined in a lint rules file. By default, the path is $GSTDIR/tools/gslint/src/default.gslint. You can specify a different lint rules file, see Enabling the lint rules file below.

When lint rules are enabled, the rules are applied at build time and errors, warnings, and informational messages are written to the Output view.

Enabling the lint rules file

To enable (or disable) the code quality tools, set these two environment variables:
  • GSLINTRULES defines the path to the lint rules file.
  • GSLINTENABLED specifies whether the code quality tool is enabled (1) or disabled (0).

Genero Studio provides the default environment set Studio Linter Tool, where you can set or alter these environment variables.

The format of the lint rules file

Lint rules are provided in the format
ruleId=value

where the ruleId is comprised of the rule type, the scope of the rule, and the rule option being set. The different types of rules are discussed below.

Enabling a rule

The .enabled option specifies whether a rule is enabled. This option is available for all rules. Valid values are true or false.

For example, to enable ruleId:
ruleId.enabled = true

Setting the severity of a rule

The .severity option specifies the severity level. This option is available for all rules. Valid values are error, info, or warning (default).

For example, to set the severity of ruleId to error:
ruleId.severity = error
Warning: If the severity is set to error, the compilation will fail if the rule is broken.

Naming conventions

The identifier naming convention rules check to verify that your naming conventions are being followed. The ruleId is context.item.identifier where:
  • context specifies the scope of the rule. The scope is one of the following:
    • globals
    • module
    • main
    • function
    • report
    If context is omitted, the scope is general.
  • item specifies the identifier type, and is one of the following.
    • constant
    • type
    • type.record.member
    • variable
    • variable.record.member
    • cursor
    • function
    • report
    • parameter
    • prepare
    item must be prefaced by context.
In addition to the .enabled and .severity options, an identifier rule can check the following:
  • .prefix checks for the existence of a constant string.
  • .characters checks for character type (alphabetic, numeric, alphanumeric, all)
  • .excludedCharacters checks for specific characters
  • .lettercase checks for case (lowerCase, upperCase, lowerCamelCase, upperCamelCase)

For example, to check that all identifiers are alphanumeric and use lowercase names, specify:

identifier.enabled = true
identifier.characters = alphanumeric
identifier.lettercase = lowerCase
To then override the general identifier rule and to specify that all identifiers in the MAIN module use uppercase and start with "M_", specify:
main.identifier.enabled = true
main.identifier.lettercase = upperCase
main.identifier.prefix = M_

DECIMAL and MONEY precision

The mandatory decimal precision rule checks to see that a precisiou has been defined for an identifier of the DECIMAL or MONEY data type. The ruleId is type.precision.mandatory, where type is:
  • decimal
  • money
For example, to check that all DECIMAL identifiers specify a precision, and to output a warning if an exception is found, you would specify these rules:
decimal.precision.mandatory.enabled = true
decimal.precision.mandatory.severity = warning

Multi-line strings

The mult-line string rule checks to ensure that a string definition does not span several lines. The ruleId is avoidMultiLineString.

For example, to check that a string does not span lines, and to output an warning if an exception is found, specify these rules:
avoidMultiLineString.enabled = true
avoidMultiLineString.severity = warning

Variable declaration (per declaration)

The first variable declaration rule regarding variable declaration checks that no more than one variable has been declared per declaration. The ruleId is oneVariablePerDefine.

For example, to ensure that only one variable has been declared per declaration, and to output an warning if an exception is found, specify these rules:
oneVariablePerDefine.enabled = true
oneVariablePerDefine.severity = warning
In this example, this declaration would be compliant:
DEFINE a INTEGER
DEFINE b INTEGER
In this example, this declaration would NOT be compliant:
DEFINE a INTEGER, b INTEGER

Variable declaration (per type)

The second variable declaration rule checks that no more than one variable has been declared per type inside a single declaration. The ruleId is typeDeclarationPerVariable.

For example, to ensure that only one variable has been declared per type inside a single declaration, and to output an warning if an exception is found, specify these rules:
typeDeclarationPerVariable.enabled = true
typeDeclarationPerVariable.severity = warning
In this example, this declaration would be compliant:
DEFINE a INTEGER, b INTEGER
In this example, this declaration would NOT be compliant:
DEFINE a, b INTEGER

Detect deprecated features

The deprecated features rules reviews the source code in your project and detects deprecated code. The ruleId is deprecated.

deprecated.enabled = true
deprecated.severity = warning
deprecated.FGLImports = FGLImport [,...]
deprecated.functions = function [,...]
deprecated.frontCalls = frontCall [,...]
deprecated.comWebServiceEngineOptions = WSEoption [,...]

For a complete list of valid FGLImport, function, frontCall, and WSEoption entries, refer to the default.gslint file as defined by the GSLINTRULES environment variable.

Detect backwards compatibility features

The backwards compatibility features rules reviews the source code in your project and detects any features that have been maintained for backwards compatibility. The ruleId is backwardCompatibility.

backwardCompatibility.enabled = true
backwardCompatibility.severity = warning
backwardCompatibility.FGLImports = FGLImport [,...]
backwardCompatibility.functions = function [,...]
backwardCompatibility.clauses = clause [,...]

For a complete list of valid FGLImport, function and clause entries, refer to the default.gslint file as defined by the GSLINTRULES environment variable.

Running the Code Quality tool from the command line

The Code Quality tool is a Genero BDL application. The executable can be found at $GSTDIR/tools/gslint/bin.

To view command line options, type gslint -h.