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
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.
format is VERS = ‘Vers 3.xxx’ but there may be some variations on this in
existing programs, i.e. VERS = "3.xxx", VERS=”Vers 3.xxx”, VERS = 3.xxx etc.
numbers for file inserts must also be updated. They should be of the
same format as for programs but must be commented.
versions of programs should begin at 3.000 if the version is currently less
- 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:
- 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
- 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 "Vx.xxx 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
- Use uppercase only, except for
- 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:
- LF.MESSAGE.SB not SB.DISP
- 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
- 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
- Dictionary items should contain
data types and must use “_” not “.” in their id’s for SQL (etc.)
- 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
- 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 >