I strongly agree with you. In these days it is far more important to have very well documented and formatted code than to be impressively complicated (certain exemptions apply obviously such as when working with huge data and speed is just as important). Unfortunately this seems to meet with a lot of resistance, even SAS developed code falls into every bad programming practice under the sun. Just take a whizz at the following example page I took from the top of a Google search for "sas code snippets":
http://support.sas.com/documentation/cdl/en/webeditorug/66932/HTML/default/viewer.htm#n002bgjjez3z63...
Code in upper and mixed case, missing run; statement, useless comments, bad indentation, RUN; not on different line etc. This is clearly visible in most of the given code, and even in the system generated code from the various SAS software now.
I would also question the "header" block. This is something which just doesn't seem to want to go away. You have written the Functional Design specification for the code, you have written the testing documents, you have coded the program and stored it in a version control system, why then the need to have:
- an audit trail, which is manually entered? Surely the versioning system which automatically can show differences, and log those against a user and datestamp all fully automatically is more robust and safer?
- a program description, which is covered in the documentation
- inputs/outputs/macro use, maybe these should be pulled out using proc scaproc at run time?
Reason being is that "manual" items are always prone to errors, let the software do these things.
I am just going to also link you across to @Kurt_Bremser's compilation of great tips:
https://communities.sas.com/t5/SAS-Communities-Library/Maxims-of-Maximally-Efficient-SAS-Programmers...
As some other ideas on coding.
Good luck with it all.