Thanks for the comments, @RW9. I totally agree with you that code in mixed formats is difficult to read, and simply inconsistent.
You make good points about the header block. I think it's still beneficial to have something at the top. If someone opens a file out of the blue, how can they know where documentation is, or at least where this program falls in the process flow? Or how it should be called? (And maybe the answer is javadoc-esque comments, which are both human-readable and can be used to automatically generate documentation.)
My organization has a standard header block (and I suspect other orgs do, too), upon which I based the version in my paper. I've found it quite useful not to highlight all changes made, but to point towards significant changes (process overhauls and non-intuitive improvements). It's great to have the audit trail point to specific revisions and/or documentation. So when I remember which piece of code was changed in some big update that was made a few months ago, the audit trail points me to where I can remind myself more.
Agreed, though, that having multiple copies of information across code and documentation is more difficult to maintain. If proc scaproc (or another code analyzer) is effective, then fantastic! I will have to play around with that.
Like I said in my intro (and the disclaimer at the beginning of my presentation), my aim is providing suggestions about things I don't see consistently used across SAS developers. I really appreciate when users like yourself are able to give feedback and further ideas.
I do cite Bremser's article in my paper 😉
... View more
