Good Programming
Practice
Rohith Chennamaneni
List of Topics
Why Good Programming Practice?
Program Header and Revision History
Assignment of Comments
Naming Conventions
Hard coding
Standard programming
2 Good Programming Practice | [Link]
Why Good Programming Practice?
• Ensure the clarity of the code and facilitate code review;
• Save time in case of maintenance, and ease the transfer of code among programmers or companies;
• Minimize the need for code maintenance by robust programming;
• Minimize the development effort by development and re-use of standard code and by use of dynamic
(easily adaptable) code;
• Minimize the resources needed at execution time (improve the efficiency of the code);
• Reduce the risk of logical errors;
• Meet regulatory requirements regarding validation and FDA 21CFR compliance;
3 Title of Presentation | [Link]
Standard Program Header
In MARVEL, the program headers are available in the
root/standards/programs/saspgm/templates (SAS) and
root/standards/programs/templates/R ®
4 Good Programming Practice | [Link]
Program Header Example
5 Good Programming Practice | [Link]
Program Header Example
6 Good Programming Practice | [Link]
Assignment of Comments
Commenting serves two important functions
1. It makes the code easier to follow.
2. It forces the programmer to review the logic of the code.
Comments should be included before each data step, proc step, and macro.
The comments should explain why the coding was done a certain way.
Organize the comments into a hierarchy.
7 Good Programming Practice | [Link]
Naming Conventions
Use explicit and meaningful names for variables and datasets, with a maximum length of 8.
For permanent datasets, use a meaningful dataset label and variable labels.
When possible, never use the same name for a dataset more than once in the program.
Note: However, keep in mind that large intermediate files take a lot of SAS Workspace.
Name IN variable using “in” plus a meaningful reference to the dataset.
Example:
data aelst;
merge aesaes (in=inae) patpat (in=inpat);
by patno;
if inae and inpat;
run;
Labels must have a maximum length of 40 characters.
8 Good Programming Practice | [Link]
Naming Conventions
The rules associated with good naming conventions for SAS data sets and variables include:
1. A name consisting of 1-32 positions in length.
2. 1st position can only be a letter (A-Z, a-z) or underscore (_).
3. Remaining positions can be letters (A-Z, a-z), underscore (_), or numbers (0-9).
4. For validation naming convention, A program name should be same as production name only difference
is add qc_ for validation program.
9 Title of Presentation | [Link]
Conventions that improve readability
Use of all upper case letters should be avoided
Separate data and procedure steps with at least one blank line
Split data steps into logical parts
Put each statement on a separate line
Left justify global statements
Left justify data and procedure statements and their corresponding run and quit statements
Indent statements belonging to a level by 2-5 columns
For do loops, place the end statement in the same position as the do statement
10 Title of Presentation | [Link]
Conventions that describe good coding practices
Do not over write existing datasets
Use the “data=dataset” option in procedure statements
Remove unnecessary code left over from previous projects
End data and procedure steps with either run or quit
Do not use tabs for indentation
Use self-explanatory names for variables and datasets
Use put and input functions when convention from character variables to numeric and vice-versa
Structure programs to read all external data at the top, do processing, then produce output
11 Title of Presentation | [Link]
Hard coding
Hardcoding is the modification of the value of an item of source data within program code.
Hardcoding is not allowed in final code.
If temporary hard coding is necessary for speed, a note to file regarding this hard coding must be made.
If any temporary hard coding is needed, programmers must:
1. Discuss with line manager and ask for approval.
2. Store the hardcoding information in a way it can be easily dropped later in case the hardcoding is only
used until data are corrected (ideally a separate program to apply the hardcoding to the dataset); the
justification must be referenced in the PTF.
3. Put warning statements in the log file, in order to identify the hardcoding step.
12 Good Programming Practice | [Link]
Hard coding Examples
13 Good Programming Practice | [Link]
Standard Programming
The implementation of standard programming techniques results in:
1. Clarity of program code.
2. Maintainability of code.
3. Survivability of code.
4. Ability to transfer code among members of the group.
5. Ability to transfer code among other programs .
6. Ability for a knowledgeable outsider to read code and understand it
14 Good Programming Practice | [Link]
Standard Programming Examples
15 Good Programming Practice | [Link]
Standard Programming Examples
16 Good Programming Practice | [Link]
Standard Programming Examples
17 Good Programming Practice | [Link]
Standard Programming Examples
18 Good Programming Practice | [Link]
Standard Programming Examples
19 Good Programming Practice | [Link]
Q&A
20 Title of Presentation | [Link]
Reference
• This is referred from a PDF Standard_Programming_Rules_v2.[Link]
• [Link]
• [Link]
21 Title of Presentation | [Link]
Thank
You