|
"Fehd, Ronald J. (CDC/CCHIS/NCPHI)" wrote:
> I would appreciate commentary on my style sheet article:
>
> http://www.sascommunity.org/wiki/Style_sheet
>
> In particular I am interested in adding to the bibliography.
New SASers coming from other html/wiki world might likely think Style Sheet
is related to a personal Cascading Style Sheet (css) for use in sasopedia.
Consider moving it to "Coding Style Sheet", or make "Code Layout Guidelines"
a sub topic of "Coding Guidelines". Coding Guidelines could have a page for
"Naming Guidelines" describing the role of name and contrasting the possible
presentations, such as:
this_variable
thisVariable
ThisVariable
THIS_VARIABLE
<type-group>ThisVariable
<role-group>ThisVariable
etc...
As for style might it be better to contrast reasonable layouts and let the
reader decide what is best for them.
Data step examples:
--Indentation hanging--
if SomeCondition then do;
Assignment1 = 'value';
Assign2 = value;
end;
--Indentation block--
if SomeCondition then do;
Assignment1 = 'value';
Assign2 = value;
end;
--Indentation full block--
if SomeCondition then
do;
Assignment1 = 'value';
Assign2 = value;
end;
--Full block indentation for complex conditions--
if SomeCondition
and Condition-2
and (Condition-3 or Condition-4)
then
do;
Assignment1 = 'value';
Assign2 = value;
end;
--Indentation for simple constrastable response--
if <some-assertion>
then <postive-response>;
else <negative-response>;
My personal alignment patterns tend towards block or full block:
statement
options-1 ...
options-<n>
;
Similar indentation rules could be recommended for statements
that call a function having several or complex parameterization
result = catx
( arg-1
, arg-2
, cats(arg-3-1, arg-3-2)
, arg-4
);
One benefit of this style is that argument order can be rearranged using
line based cut and paste.
Similar patterns are beneficial when coding complex SQL statements,
especially the select clause.
There is potential flaming between the camps espousing
- 'operators/separators belong at the front of the line', and
- 'operators/separators belong at the end of the line'
when dealing with multiline statements.
All these topics have no doubt been repeated in any number of programming
language discussion communities.
As you have stated numerous times, the ability to observe alternation within
repetition is essential to understanding. Code with that mantra in mind.
--
Richard A. DeVenezia
http://www.devenezia.com/
| 
