Failure to comply with any of the following criteria will cause an upgrade to fail the code review. Please note that these are the minimum standards that code should conform to.


  • Previous versions of the programs should be stored for comparison purposes. ARev programmers should use the QUPGRADE utility before making amendments. UniVerse programmers should use the Files / Backup button in UVEdit


  • The upgrade tools should automatically store previous versions as theupgrades are built.  The internal version number must updated, must be on line 4 and must occur only once within the program.

The correct format is VERS = ‘Vers’ but there may be some variations on this in existing programs, i.e. VERS = "", VERS=”Vers”, VERS = etc.

Version numbers for file inserts must also be updated.  They should be of the same format as for programs but must be commented.

New versions of programs should begin at 3.000 if the version is currently less than 3.

  • New functions must contain details of the following:
    • Description of the functionality of the process.
    • Description of the parameters passed in and out of the process and their range.


  • The version control section in the program header must be updated and contain: 
    • Version number
    • number
    • Date 
    • Initials
    • Brief description


  • Code changes:
    • Hard coding should never be used in programs. Typical examples that will be rejected are:
      • Plan codes
      • Status codes
      • Company settings
      • Currency settings
    • Upgrades will be failed if standard routines are not used for common functions.  Examples of such routines include:
      • LF.CCY.CONV
      • LF.DT


  • Readability:
    • Never use GOTO, STOP, RETURN TO, numeric labels etc.
    • New programs – avoid using common area for passing parameters
    • Structure code correctly avoiding linear programming, by using GOSUB's to reference repeated or subsidiary program elements.
    • Indent code clearly  (2-3 spaces recommended)
    • Variable names must always be meaningful. Try to keeps these concise to avoid spelling mistakes.
    • Never use nested IF constructs for multiple branching, use CASE statements.  ensure that there is a  CASE 1 condition associated with the conditions
    • No multi- statement lines are allowed except comments.
    • Comments - document new subroutines and chunks of code with meaningful comments that assist subsequent developers understand the code. Meaningful comments are fine, but there should not be " start" or "...end" comments anywhere in the body of a programme.
    • Remove out of date or useless comments or update them where possible. 
    • Previous lines of code may be retained where they add meaning to the amendments. Programmers may use their discretion.
    • Use uppercase only, except for comments
    • Lines of greater than 80 characters should be split for clarity where possible.
    • Code which is not readable will be rejected. Where there are no size restraints spaces, brackets and possibly alphabetic boolean comparitors should be used for clarity.
      • i.e. “IF VAR<1><>VAR2  AND VAR<3>>VAR4 THEN …” is far more maintainable written in the following format: -
      • “IF (VAR<1> NE VAR2) AND  (VAR<3> GT VAR4) THEN … “
    • If error conditions are not trapped at suitable points, the code will fail review:
      • i.e. use of ELSE, CASE 1 etc. where fatal errors have not been considered.


  • General failures:
    • Never use SB+/ARev specific routines, use for example:
    • No DEBUG statements or messages should be left in the code, even if commented or user id specific. No INPUT or CRT statements are allowed, LIFEfit routines should be used.
    • No error messages requiring a user response are allowed in the batch routines unless processing has fatally terminated and cannot continue. If used the batch must terminate entirely and the users must be aware that it has done so. All other error messages should be directed to the printer (or other output device) using the WHERE parameter in LF.MESSAGE.SB)
    • Keep code portable, i.e. standard PICK code. Deviation from this standard will cause instant failure of the review. Typical failures are use of reserved words like COUNT for variables, unsupported statements like “X = IF Y THEN 1 ELSE 2” or “IF … THEN … THEN”
    • Dictionary items should contain data types and must use “_” not “.” in their id’s for SQL (etc.) compatibility.
    • New dictionary items must also exist in the INSERT for that file. Treat the insert item as the control record for the file and update this first if necessary.


  • Other items of note:
    • Reviewers will note problems with programs on the review forms even if the problems have not been introduced by the amendments. Please be aware that this is not a failure condition but merely a way of logging existing problems with the code.
    • The upgrades themselves should contain meaningful comments and user instructions. If no meaningful comments are applied then the upgrade will be failed before a single line of code is reviewed. I.e. if you add a field to one of the plan screens then ensure the upgrade has instructions how to and where to update that field and whether it is mandatory.
    • Some concern has been raised over several amendments being made in one day under the same WTI and being issued as separate upgrades.
    • While this is not strictly a code review matter it must be noted that each code review requires a programmer to be allocated and submitting multiple upgrades for the same WTI is a waste of programming resource.
    • As the code reviews are allocated against WTI analysts should be aware that the allocation is traceable through Taskfit.

< Top >