PROGRAMMING TECHNIQUES
This
section covers general programming techniques that should be used to make the
code easier to read and additional general LIFEfit specific programming
techniques.
a. IF ... THEN ... ELSE statement
- Ensure the construct is easy
to read
- Don't write:
IF VALID=5 ELSE
.. Statements
END
IF VALID<>5
THEN
or
IF VALID = 5 THEN
..
statements
NULL
END
END ELSE
... statements
END
- Keep to the following
construct:
IF
COUNTER > MAX_PLANS THEN
LF.MESSAGE(.....)
END ELSE
GOSUB EDIT
END
IF COUNTER>MAX_PLANS THEN LF.MESSAGE(...) ELSE GOSUB
EDIT
- Distinction should be made
between values null and '0'. For example when checking if value had been
put into a screen field the variable should be checked like this: IF
WC_IS%<>'' THEN because in some cases 0 is also a value.
>
Top <
b. Case statement
- LIFEfit’s strength is its
flexibility. The changes that we make today will be changed again
in the near future. If you are adding a calculation to an existing
calculation routine, then always use a CASE statement. IF…END
ELSE.. Works for binary choices, but will be a mess the third time round.
- If you use a CASE statement,
make sure the code is easy to read and if the code is too long then
create an internal subroutine.
DO:
NOT:
BEGIN
CASE
BEGIN CASE
CASE CODE =
PARM
CASE CODE = PARM
GOSUB
AGE_CHECK
(Page of code)
CASE CODE =
PARM
CASE CODE = PARM
GOSUB
OCC_CHECK
(half a page of code)
END CASE
END CASE
CASE
1
CASE 1
CALL LF.MESSAGE.SB ('LF009',
", ", program name:field mark:func:field mark:programe
version number)
>
Top <
c. Displaying messages
- Do not use MSG, SB.DISP or
CRT in your code – if you do, the new Upgrade Procedure will refuse to
download that program. Use the standard function (LF.MESSAGE in
Advanced Revelation and LF.MESSAGE.SB in Universe) to display a message
to the screen or to print any messages in a report file.
d. Semicolons
- Do not use semicolons to put
multiple statements on a line (except comments). Keep lines
simple.
DO
NOT
VAL = 0 ; * Initialise
value
* Initialise Variables
IINCR = 1 ;* Initialise
increment
VAL = 0;INCR=1
>
Top <
e. Future file
- FUTURE records should contain
the minimum of information. It should be required only to have the
key information, the COMPANY CD, and DATE and TIME of request.
This will minimise the overhead in creating or amending future
records. FUTURE records for forward switches, surrenders, income
payments, etc should also contain the key to the related record in the
UNITSWITCH QUOTE or IPAYMENT record respectively.
- Wherever possible, FUTURE
records should be written from a central routine, LFS_FUTURE
f. Changes to codes
- If a code is being changed
(i.e. from number to alpha), check for uses of that code throughout the
system.
g. Insert files
- Never use field position
numbers in your programs, always use equates from the insert
file. The equate entry in the insert file should match the
dictionary field name i.e.:
- Premium_Received fields on
the POLICY file.
- The insert file POLICY_INS
should contain PO$PREMIUM_RECEIVED
- On the UniVerse system, the
insert files contain version numbers. Update the version number
when the insert file is changed. The format for version number is
VERS=3.xxx and resides on line 4.
> Top <
h. Screen based programs
i. Field processing:
- Only one Parameter should be
passed from a screen which should adhere to the following standard
format:
PRE_fieldname
Pre prompt process call
POST_fieldname
Post-prompt process call
OPT_fieldname
- (Note: A case could also be
made for ‘VALID_’, ‘SET_’, ‘GET_’, ‘DEFLT_’ as alternative prefixes
where these are more descriptive.)
- ‘PRE_action’ or ‘POST_action’
where action is of the form ‘SAVE’, ‘INIT’ ‘DELETE’ or other action or
event associated with the screen as a whole ‘PERPETUAL’ for a
perpetual process
- The main section of the
program should consist of a CASE construct, with one CASE statement per
parameter option, and terminated with a RETURN. A ‘CASE 1’ error
procedure should trap and report any invalid options. Each
non-trivial case should branch to an appropriately named internal
subroutine. The name of internal subroutine should be the same as
the passed parameter.
ii. Softkeys:
- Options should have
descriptive names, not function key numbers
- Soft Key options launching a
complex screen or process should be limited to setting parameters and
invoking an external subroutine.
> Top <
i. Input/output statements
- Never use OPEN, READ, WRITE
DELETE statements in your programs. There are sets of standard
programs to do this. These programs start with LFSIO and are
listed below:
LFSIO_STATUS
I/O status file
LFSIO_CODES
I/O Codes file
LFSIO_FUTURE
I/O Future file
LFSIO_COMMTYPES
I/O COMMTYPES file
LFSIO_GENACCTRN
I/O GENACCTRN file
LFSIO_COMMENTRY
I/O COMMENTRY file
LFSIO_UNITMOVES
I/O UNITMOVES file
LFSIO_PLANS
I/O PLANS file
LFSIO_MASTER
I/O MASTER file
LFSIO_POLACCTRN
I/O POLACCTRN file
LFSIO_UNITACCTRN
I/O UNITACCTRN file
- Input / output to any other
data file should use LFSIO_DATAFILE.
- There is no need to open the
datafile before the read. Call the LFSIO process with READ
parameter, it will open and read the file.
- When saving a numeric value
onto a datafile, ensure that the value is rounded before it is saved,
i.e. if 1234.5678900 is being saved onto the policy, round this before
storing onto the policy, save as 12345.
> Top <
j. Batch processes
i. Batch message:
- Use the standard batch
message LF_BATCH_MSG in the batch processes. This message shows
the progress of the batch process by showing the total number of records
to process and the number completed.
ii. Reports:
- Report page and column
headings should be created using the standard Lifefit programs
LF_COLHEAD and LF_PAGEHEAD.
-
The report number should be
added to the LF_MASK for new reports. All new report number as of now
will start from 1000. When a new report number is required, check the
last number used and increment by one
e.g. |
|
first new report - REPORT_1000 |
|
|
second new report - REPORT_1001 Add the new report number to the codes
record REPORT_TITLES |
iii. Policy status:
-
NEVER
use PO$POLICY_STATUS_CD or PO$STATUS_CD directly in conditional statements
(IF, CASE), these fields hold the external status code which is user
configurable. If comparisons in the program are made against the external
status code then that is like hard coding the statuses within the program. The
client has the ability at any point to change the external status code but
what will remain constant is the real status (Status Type field on the status
set-up screen). Policy status comparisons should be made against the REAL
status.
- There is a standard program
that returns the REAL status:
POLICY_STATUS
=POLICY_REC<PO$POLICY_STATUS_CD>
LFSIO_STATUS('REAL','',POLICY_STATUS,REAL_POLICY_STATUS)
IF REAL_POLICY_STATUS='P' THEN *
PENDING POLICY
> Top <
iv. Batch status change:
- When
setting up a new automated status change, batch process ensure
LFSCH_WRAPUP is called to do the status change. The batch process should build up the parameters and call
LFSCH_WRAPUP. This will ensure that
the batch and the on-line status change processes are consistent.
k. Tools
There are tools available to assist with development:
i. UVEditor:
- Always use the Uveditor
when editing programs or inserts.
ii. SSCAN search:
- If you are changing an
existing program or want to know how a field works, use SSCAN in AREV or
the search functionality in the UVeditor to help you.
- These functions look through
a designated table for a given string. The string search should be
using the least common denominator. If you are looking for
enhancements to trailer commissions, then use the string PL$TRAIL rather
than PL$TRAILER_COMMISSION. This will catch all PL$TRAILER or
PL$TRAILS, etc. etc. This will produce a list of items where the
required string is used, in AREV a BROWSE LIST will be created for easy
analysis.
iii. family_tree:
- If you are modifying a
program or are unsure of the implications of a change to a program, then
run FAMILY_TREE in AREV or the Family tree option in UVEditor to will
give you a top-down look at the subroutine in question and all the
routines that are called from this routine. The POPUP window will
allow you to edit any of the called programs.
> Top <
l. New pseudos
- Avoid using the underscores
when defining new accounting pseudos.
m. Rounding
- If developers are updating
numeric fields through a program, then they should check the data by
editing the record to ensure the data is rounded. A problem has
been discovered with INT when rounding negative numbers. User MR0
conversion instead of the INT function.
> Top <
|