As the first step in the decommissioning of sasCommunity.org the site has been converted to read-only mode.
Here are some tips for How to share your SAS knowledge with your professional network.
Talk:Style guide for writing and polishing programs
note: changed name from 'Style sheet' to 'Style Guide' per user commentary that it shows up, inappropriately, when searching for 'cascading style sheet'.
did some polishing this morning. --macro maven 10:58, 7 May 2007 (EDT)
LOL well, you 21st century folks need to know that magazines, newspapers, and publishers have had 'style sheets' since the year after Gutenberg invented the printing press.
See Chicago Manual of Style
and New York Times
I am willing to change the name of the article. As others have already pointed out, I might have said 'My Style Sheet' or R.J. Fehd Article of Programming Style.
I am considering calling it: '(My) Best Practices'
or 'Programming Style and Usage'.
I am pleased that I got some comments on this.
thanx: "Dialogue moves us forward!"
--macro maven 11:28, 4 May 2007 (EDT)
The following comment was made by User:Savian
I think style sheet is a wrong description here. Style sheet refers to CSS in common parlance so using SAS code in a style sheet discussion, to me, is very misleading.
And this comment was by User:Rdporto
I agree that 'style sheet' can be a little confusing. To be sincere, I thought it was about CSS using SAS...
Maybe it could be titled like Joe Celko's book: SAS Programing Styles
A couple of thoughts on this:
- I agree that Style Sheet can cause confusion for others since it is an industry standard term for html style sheets.
- I don't like the convention of upper case for DATA and PROC and proper case for other names.
- I actually like using bumpy or camel case for names, e.g., firstName.
- I would suggest that if one wants to use a convention for temporary variables, perhaps beginning with __ is a better choice.
- I find the suggested structure for do-end very hard to read and much prefer a structure like
if <condition> then do; /* comment about this */ -------- The following comment was made by user Plf515, not by Donh: I don't use CAPS except for comments. Not only does this make them stand out, it also separates what might be called permanent comments from those that will be commented out at certain times -------- end; /* comment about this */
- I also do not like embedded macro comments in code - would much prefer /* */ style comments.
--Donh 14:49, 3 May 2007 (EDT)
Most of what comprises programming style is intensely personal. Each style is different, and we obviously think our own style is the best and all others lacking in some regard. In fact, we think some programming styles are downright ugly and hinder program development / maintenance. Some of our preferences have roots, eg. working with *nix has taught me to never use capital letters, and that has extended to include variable / data set names etc... It's just a useful habit I've gotten in to that keeps me from messing myself up in the *nix world where case sensitivity is a reality. Rather than bumpy or camel notation, I use the underscore to separate words. But, others are able to compartmentalize *nix and SAS in their brains and they don't mess up so camel notation works for them.
Because programming style is so personal, I question whether a post on programming style is necessary and/or valuable. Perhaps what's more helpful is something that outlines things that really do matter and ( usually ) aren't a matter of style per se. eg. a useful comment block at the top of every program, explanatory comments, including run; statements after your steps, using verbose variable names to convey meaning etc...
--harry 10:08, 4 May 2007 (EDT)
I agree that programming style is greatly personal. However, newbies (and even experienced) programmers can learn from good habits. Of course, you could always cite some good books on this subject but, since we're programming in SAS, it's better to see examples in SAS.
A good approach is that proposed by Richard DeVenezia at SAS-L. This means to present the options together with the "why's" (pros and cons), and let the reader decide.
--Rdporto 21:26, 3 May 2007 (EDT)
A couple comments:
1) adding comments to the END statement on a long DO group can be helpful in matching, particularly in macros. e.g.
if x = 1 then do ; ''...much SAS code...'' end ; /* end of if x=1 do block */
2) Use of a %SKIP macro is a useful technique to comment out blocks of code. It avoids problems with embedded /* */ code in what you're commenting out.
e.g. %macro skip ; ''SAS code to comment out'' %mend skip ;
I took the liberty to insert a few subsections in the main article to facilitate the reading and reordered a few items accordingly. No offense. I hope this makes sense.
I was not sure about the bullet point: Use Two.Level Data.Set Names. What's the benefit/purpose of doing that?
Moreover I think the example code following that is more about spacing than using two-level dataset names. I would suggest, having identified the rationale for two-level names, to just mention it as a note here but explain it in a separate (linked) section or page (with other related recommendations).
Besides, I completely agree with the view to present the options together with the "why's" (pros and cons), and let the reader decide. :-)
I would like to copy to the main page the additional elements that emerged as part of the discussion on this page. Maybe further additions could be done directly on the main page? It seems the policy on a wiki is to allow everyone to edit the contributions from anyone else, to improve the page content. It would probably be much better to combine related elements on the same page, than to have them spread across many pages by different authors.
Jmbodart 05:26, 30 September 2008 (EDT)
Hanging indent is confusing
I like the article but cannot stand having the termination command indented rather than at the same level as the start of the command. You seem to be recommending
if a=b then do; ... end;
Instead of the more scanable.
if a=b then do; ... end;
SAS is a delimiter based language unlike Python.