Date:         Thu, 3 May 2007 16:03:05 -0400
Reply-To:     Don Henderson <donaldjhenderson@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
Comments:     RFC822 error: <W> MESSAGE-ID field duplicated. Last occurrence
              was retained.
From:         Don Henderson <donaldjhenderson@HOTMAIL.COM>
Subject:      Re: OT: style sheet
In-Reply-To:  <G%q_h.67$9b3.73801@news.sisna.com>
Content-Type: text/plain; charset="us-ascii"

Richard (and Peter),

I agree with many of your comments. Permit me to suggest that you should
consider adding them to the page which is the discussion page for the page
that Ron wrote. And if you do that, make sure to use the editor button to
"sign" your comments.

Regards,
-donh

> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of
> Richard A. DeVenezia
> Sent: Thursday, May 03, 2007 3:44 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: OT: style sheet
>
> "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/