VSC overview

You can use VSC to:

• Check whether software development is done according to the Infor LN coding and programming standards.
• Search for inconsistency in the tools dictionary.
• Search for suspicious constructions.
• Search for constructions the compiler will let through. For example:
  • (Dynamic) function implementation.
  • A message code is used in a script or library, but the message is expired or not present.

VSC checks the following software components:

• Messages
• Questions
• Sessions
• Domains
• Tables
• Menus
• Forms
• Scripts (all types)
• Reports

To perform quality checks, VSC applies various rules that are based on:

• The Infor LN Software Coding Standards (SCS) - a set of standards that define how each software component type must be coded. For example: the coding standard for dynamic sessions is pp mmm s f xx o y cc. where:
  • pp - package code
  • mmm - module code
  • s - submodule code
  • f - function code
  • xx - sequence number
  • o - type of process
  • y - session sequence number; if more than one session is present for the same main table, this sequence number can be used to define the different sessions, starting with 0
  • cc - customization type
• The Infor LN Software Programming Standards (SPS) - a set of standards that define how engineers must write scripts and libraries. These standards make it possible to:
  • Share good programming practices
  • Provide standard programming solutions and style
  • Manage complexity
  • Write code that is easier to understand (especially for other developers)
• The Infor LN Performance Guide - a set of guidelines for optimizing the performance of the Infor LN software.
• Practice
• Dynamic tests

Some examples of rules are:

• A message called in a script, should not be expired.
• A function used in a form command, must exist in the session's UI script.
• A DALHOOKERROR must be followed by a dal.set.error.message().
• A business method called in a UI script, must exist in the DAL.
• A query that performs an update must have a 'with retry' clause.
• The number of parameters in a message call must match the number of parameters in the message description.
• A question must have a default answer.
• The length of the session description label in a form command must fit on a button.
• Field specific buttons in a form must have bind type 'field'.

Each verification code is linked to:

• One or more package combinations.
• One or more verification filters. These filters define the checks that will be performed by VSC.

For each verification filter the following properties are defined:

• Priority Filter: determines the type of warnings ("FiItered to Handle" or "Non-filtered") that VSC must generate for the various error types, and whether these warnings can be accepted, or must be blocked.
• Category Filter: determines the type of warnings ("FiItered to Handle" or "Non-filtered") that VSC must generate for the various types of checks ("General" checks, "Tools Consistency" checks , "Application Logic" checks, and so on).
• Per component type: the checks that must be performed. For example: for forms, you can perform checks on standard options, specific options, buttons, various form field options, and so on. For tables, you can perform checks on table fields, indices, reference fields, messages, and so on.

VSC generates warnings as a result of the checks that are defined for the verification filters. Depending on the filter settings, VSC generates:

• "Filtered to Handle" warnings. You must handle these warnings immediately. You must either solve or accept these filtered warnings.
• 'Non-filtered' warnings that you do not have to handle immediately.

Each warning has various attributes, such as:

• Verification code.
• Component Type.
• Component, subcomponent and line number where the error occurs.
• Priority: high, normal, suspicious, or low.
• Category: General, Tools Consistency, Application Design, Application Logic, Standards, Text, Performance, Integration, Runtime, or Export.
• Message ID and message text.

The sessions are grouped in the following menus:

• End Users. Contains sessions to verify software components and to view, print and handle the generated warnings.
• Administrators. Contains the following sub menus:
  • Verification Codes. Contains sessions to configure VSC.
  • Warnings. Contains sessions to copy, move, or delete the generated warnings.
  • Import/Export. Contains sessions to transfer VSC data to another development environment.
  • Miscellaneous. contains miscellaneous administrative sessions.