Do you use best practices for writing and sharing code? Do you want to learn, discuss, and improve?

[paulkaefer]

Come see my talk, "Code Like It Matters: Writing Code That's Readable and Shareable", on Tuesday, April 10 from 5-5:30 PM in Room 504. Let's bridge the gap between traditional software engineering best practices and SAS coding standards!

For a preview, see my SAS Communities Library article and/or the sasCommunity.org page for my MWSUG paper on which the SGF paper is based.

If you can't make it, I'd love to connect to discuss feedback and your own best practices.

[RW9]

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.

[paulkaefer]

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 😉