Good Programming Practice
Introduction |
---|
The Good Programming Practices are defined in order to:
Note: As often, the various guidelines provided hereafter may conflict with one another if applied in too rigorous a way. Clarity, efficiency, re-usability, adaptability and robustness of the code are all important, and must be balanced in the programming practice. |
Regulatory Requirements | |
---|---|
Validation | Reading the 21CFRPart11 actual documentation is helpful. While it is long and written in government speak, you can read it and interpret it for yourself. 21 CFR Part 11 |
Readability and Maintainability | |
---|---|
Language | English is an international language and study protocols, study reports for practical reasons (regulatory authorities, inlicensing, outlicensing, partnerships, mergers) are mostly written in English, therefore it is recommended to write the SAS code and comments in English. |
Header and Revision History |
---|
|
**********************************************************; * Program name : * * Author : * * Date created : * * Study : (Study number) * (Study title) * * Purpose : * * Template : * * Inputs : * * Outputs : * * Program completed : Yes/No * * Updated by : (Name) – (Date): * (Modification and Reason) **********************************************************;
- In addition to your name or initials, use your login ID to identify yourself in the header. This is so there is no ambiguity on the identity of each programmer.
- Update the revision history at each code modification made after the finalization of the first version of a program.
Note: When you copy a program from another study, you became the author of this program, and you should clear the revision history. You can specify the origin of the program under the “Template” section of the header. Text is available under the Creative Commons Attribution-ShareAlike License ; additional terms may apply. See Terms of use for details.