Add the BaaN project number and an identifying description to the beginning of the script after all previous customization descriptions. Add object identification after all previous identifications.
At the beginning of the script, after existing comments…
|* <Session Code> VRC <VRC_Name>
|* <ID>, <username>, <date>
|* Script modified for something
At the beginning of the script, after existing object identifications…
#ident “@(#)<ID>, <username>, <date>,<VRC_Name>”
For new customized code…
If condition then |<ID>.sn
Where: . sn is the start of new code
.en is the end of new code
.n is one line of new code
For omitted code…
| If condition then |<ID>.so
| endif |<ID>.eo
Where: .so is the start of omitted code
.eo is the end of omitted code
.o is one line of omitted code
If more than one developer is making changes under the same project number, include the developer’s initials with the project number.
2) OBJECT NAMING CONVENTIONS
New objects: ppmmmxxxx for scripts, functions, DLL’s
ppmmmxxxxm000 for sessions
ppmmmxxxxm0001 for forms, menus
ppmmmxxxx01000 for reports
Where: pp = Package
mmm = module
xxxx = standard BaaN convention for number
3) CODING GUIDELINES
Exceptions: Changes to tables, and DAL scripts should be prevented wherever possible.The creation of new Domains should be prevented, too. Every change on a Domain needs “Create Runtime Data Dictionary” in the Production Environment
Session numbers are in the format:
<package> is two letters, the package code
<module> is three letters, the module code
<number> is created by inserting a session type digit between the first digit of the main table number and the last two .
<type> is in BaaN LN: ‘m’ for a multi occurrence session, ‘s’ for a single occurrence session.
<digits> should be 000 unless there are reasons to change this (see below)
Standard session type digits are:
1 – maintain
2 – update
4 – print
5 – display
Digits 0, 3, 6, 7, 8 and (if necessary) 9 are considered “unassigned”.
The same number/digits combination should not be used for a session and sub-session unless they have (mostly) identical functionality.
Exceptions: If a session doesn’t use any tables (i.e. a session that copies files from the local machine to the server), instead of <number><type><digits>, a meaningful description can be used (i.e. tgxxxcopyfile)
Reports numbers are obtained by replacing the type letter (m or s) in the session number with two digits. The first digit is the report group, the second is the report number. If the report number is greater than 9, letters should be used starting with ‘a’.
Occasionally, a report is used by more than one session. In this case the report is simply assigned to the second session – there is no need to create a duplicate report.
Program scrips are generally in the format:
where <package>, <module> and <number> are derived from session. Additional letters and/or digits must be added if a different script is required for a sub-session or if there are multiple sessions that share the same <number>.
<number> should be either a 4 digit number or a meaningful description (preferred).
Again, <number> should be either a 4 digit number or a meaningful description.
4) DOS AND DON’T’S
A) Always use the order by clause when using as set with n rows, unless the returned data is not important .It ensures code portability. With level 1 drivers, the Baan driver will automatically issue an order by hash1 to the SQL server if no index is used in the where clause and no order by clause is present. With the level 2 driver, the driver will not send any default order by clause to the server and the rows will be returned in whatever order the SQL server considers faster.
B) Do not use where expressions that don’t involve table fields, just external variables and constants
C) Use full domain constants for enum domains to increase readablity of the scource code. Avoid use of functions like ltoe.
Ex: use temp = tcyesno.yes instead of temp = ltoe(1)
D) Use db.set.to.defaults before insertion of new record in table. This will ensure that if value is not assigned through program, default value mentioned at table level will be picked up.
E) Messages: Hard coding of messages must be avoided in program scripts. Commonly used messages may be re-used if we can maintain this as a standard.
F) Referential Integrity: It is mandatory to add references to existing master table whenever new tables or new fields are created.
Adding references to existing master tables will save the efforts of adding data validations at DAL or script level.
G)Avoid Hard Coding: In an effort to make customizations generic, we need to make specific guidelines for ourselves to avoid hard coding of values.