Sunteți pe pagina 1din 3

T24 Coding Standards

Check out the standard coding practices followed.

1 Subroutines should be less than 600 lines excluding comments.


2 All code shoule be structured in a modular fashion and broken into small units/paragraphs
less than 60 lines.
3 Program should begin with brief comment describing the functional characterstics and in
what circumstance its called.
4 The description should not describe the implementation details(How it does it)because these
often chang over time.
5 Arguments passed to a subroutine should be described when their functions are not obvious
and when the subroutine expects the arguments to be in a specific range. Variables that are
changed by the subroutine, especially those passed as arguments, must also be described at the
beginning of each subroutine.
6 Please do remember to mark the start and end of the code changes as part of the code when
existing code has change.
7 Labels and variables should have meaningful names.
8 Sign of special characters are not allowed: !@#$%^&*()+=|\/?<>~`’”-
9 Labels and variables must all be in uppercase
10 For frequently used or long terms, standard abbreviations are recommended to help keep
name lengths reasonable. In general, variable names greater than 32 characters can be difficult
to read.
11 Never use different variable names to hold the same value except in cases where the values of
the variables are bound to change during the execution.
12 Should not use READU instead of F.READU
13 Use OFS.POST.MESSAGE instead of OFS.GLOBUS.MANAGER
14 Do not use input function
15 Do not use RETURN TO unless it is used as an exit point for the routine
16 Using direct WRITE on core files to be cheked instead of F.WRITE
17 Do not use single line statement(inline function)
18 CACHE.READ should used for PARAM files instead of F.READ
19 More than 3 nested if is not allowd
20 Redudant code should remove and it needs to be create separate API
21 Do not assign the values in the common varaiable such as
F.LOCKING,R.USER,R.COMPANY R.DATES and TODAY etc
22 Do not use GOTO unless it is to exit a unit, or is used to retry the read of a locked record
23 Avoid deeply nested IFs and large CASE constructs. If an IF construct exceeds 20 lines then
use a GOSUB - nothing is harder to follow in a program than an IF that starts on page 1 and
ENDs on page 21. Try to reverse conditions if large nested Ifs are attempted
24 Labels, variables and routines should not use the same names
25 No hard coding of any sort should be done in programs. All specific data needed in the
program’s logic should be set up using either local references in existing tables depending on the
type of data objects or new tables/ parameter file should be created (as templates) which will
hold these data items. This includes paths to unix scripts – use a VOC to get the path before
calling the script. If hard coding is unavoidable use global variables
26 Do not pass common variables as arguments to subroutines
27 If no of argument is more than 5 try to use common insert files between the subroutines
28 Do not use condition selection in any anywhere to avoid performance issue
29 Each routine/subroutine should have a suffix “R” to identify if it is reusable or not
30 Do not use STOP or ABORT
31 All subroutines, both the subroutine itself and internal subroutines, should return from a
single exit point.
32 Subroutine names and variable names should be in upper case and should be as long as
necessary to describe their purpose
33 subroutine names should be limited to 35 characters.
34 subroutine names should begin with the product prefix and then describe the routine
35 For frequently used or long term names, standard abbreviations are recommended to help
keep name lengths reasonable
36 Subroutine names should not include the “$” or “_” character.
37 All routines MUST have I_COMMON and I_EQUATE inserted at the start of the program
38 To perform the operation 'Read, writes' use "F.READ, F.WRITE"
39 To perform the operation 'File Open' use "OPF"
40 Use Include instead of Insert for the inclusion of files
41 Variables names should be long and meaningful.
42 Labels, Variables and Routines should not use the same names
43 Labels and variables should have meaningful names. Numeric labels should not be used
44 Record variable should be defined as R.filename
45 File Variable should be defined as F.filename
46 Common variables should not be passed as arguments
47 Do not use Keywords as variables
48 When using abbreviations make sure they are consistent throughout the entire application.
49 Always add ‘reserved’ variables to common blocks as this avoids common mismatches when
adding new variables.
50 All keywords used must always be coded in capital letters.
51 Do not use Keywords as variables
52 Avoid using FOR…NEXT loops, use the more efficient LOOP…REMOVE syntax
53 If an IF construct exceeds 20 lines then use a GOSUB
54 Construct case statements so that the most often used condition is at the top. To ensure
performance
55 Do not perform counts in the controlling section of a loop to ensure performance
56 No routine should have multiple calls to GET.LOC.REF for the same application.This will
cause performance issue.
57 Large dynamic arrays (greater than 1000 bytes) should be avoided
58 Fields must never be reference by their field number, except in conversion subroutines.
59 DO NOT comment out existing code DELETE it.
60 "DO NOT use asterisks (*) to create coding breaks, either use the “*---------------“,,
to make code more readable."
61 DO NOT embed the CD numbers in the code as separate lines, always append to a line of
code.
62 "Query names for a Data Access Services should start with “das” followed by the name of the
application and, finally, the name of the query"
63 If there is a need to bypass T24 subroutines to perform delete (F.DELETE) & write
(F.WRITE), then syntax in these statements must avoid the ELSE & THEN verbs and instead
make use of only the ON ERROR verb.
64 In case the program has been coded as ‘PROGRAM’ instead of subroutine the statement
used to exit the program must be coded as ‘STOP’ and not ‘RETURN’
65 "Do not write TOP DOWN code. Each routine should have one main controlling section with
the detailed code written as subroutines."
66 All called arguments and common variables used should be documented in the called
routine.
67 When calling API interfaces or user defined subroutines do not use the program as the flag
68 "The first line of the program should be a comment line; the second line should be the
SUBROUTINE
(or PROGRAM) statement. The next few lines of the program should be a brief description of
what the program does."
69 Use the first line after the label to describe what the routine does.
70 Put the CD reference on the end of the code. Use S to indicate Start of change & E to indicate
End of change.If the change only affects one line of code then use S/E.
71 Whenever any fields in the INSERT file is modified, all routines using the INSERT file must
be recompiled
72 All routines must have I_COMMON and I_EQUATE inserted at the start of the program

S-ar putea să vă placă și