Startseite » SAS-Programmierrichtlinien » Codelayout » Platzieren von Anweisungen

Anweisungen mehrzeilig

Eingetragen von AndreasMangold. | 22 März, 2006 - 00:11

Wenn eine Anweisung mehr als zwei Objekte (Variablennamen, Dateinamen, Makroparameter etc.) enthält, wird jedes Objekt auf eine neue Zeile geschrieben und die Anweisung wird so formatiert, dass man ohne weiteres neue Objekte hinzufügen oder vorhandene löschen kann, ohne die Anweisung insgesamt zu verändern. Das bedeutet auch, dass man das schließende Semikolon auf eine eigene Zeile schreibt und dass man in durch Kommata getrennten Listen die Kommata jeweils an den Beginn jeder Zeile statt an das Ende schreibt.

Begründung: Dadurch wird es einfacher, bestehenden Code zu überarbeiten, insbesondere, weitere Variablen hinzuzunehmen oder auch Variablen von einer Anweisung in eine andere zu kopieren. Auch kann man einfacher eines oder mehrere Objekte innerhalb einer Anweisung durch /* */ auskommentieren.

Beispiel im DATA-Schritt

data staedte;
   length
      land   $ 30
      stadt  $ 30
      xkoord 8
      ykoord 8
   ;
   label
      land   = 'Bundesland'
      stadt  = 'Hauptstadt'
      xkoord = 'X-Koordinate'
      ykoord = 'Y-Koordinate'
   ;
   format
      xkoord ykoord time8.
   ;
   informat
      xkoord ykoord time.
   ;
   input
      land
      stadt
      xkoord
      ykoord
   ;
datalines;
Hessen Frankfurt 8:41 50:07
Bayern München 11:35 48:09
;

mit ATTRIB wird es noch übersichtlicher

data staedte;
   attrib
      land   length=$30 label='Bundesland'
      stadt  length=$30 label='Hauptstadt'
      xkoord length=8   label='X-Koordinate' format=time8. informat=time.
      ykoord length=8   label='Y-Koordinate' format=time8. informat=time.
   ;
   input
      land
      stadt
      xkoord
      ykoord
   ;
datalines;
Hessen Frankfurt 8:41 50:07
Bayern München 11:35 48:09
;

Beispiel für SQL

proc sql;
   select
      bestellung.id     
     ,produkt.id
     ,produkt.name
     ,bestellung.anzahl * produkt.preis as gesamtpreis format=commax10.2
   from
      order
     ,produkt
   where
     bestellung.produktid = produkt.id
   ;
quit;
Wenn man die Kommata an den Anfang der Zeile schreibt, vergisst man sie weniger leicht.

Beispiel für Makro-Aufruf:

%mahn3(SGE=WP
     , VKORG=1030
     , VTWEG=              /* alle VTWEGe */
     , MM_Info=no
     , JJ_Info=no
     , MManz = JA          /* der TABULATE ist ... */
     , atag_von=           /* leer=default */
   /*, atag_bis=20060228 */
     , atag_bis=           /* leer=default=keine */
     , kumvar=auft         /* Kumulierung auf Auft */
     , scorvar=CEG         /* leer=autom. CEG-Scorewerte*/
   /*, tstinlib=dmworkOI */
     );

so sollte man es dagegen nicht machen

data staedte;
   length land $30 stadt $30 xkoord 8 ykoord 8;
   label land='Bundesland' stadt='Hauptstadt' xkoord='X-Koordinate' ykoord='Y-Koordinate';
   format xkoord ykoord time8.;
   informat xkoord ykoord time.;
   input land stadt xkoord ykoord;
datalines;
Hessen Frankfurt 8:41 50:07
Bayern München 11:35 48:09
;

und so auch nicht

proc sql;
   select bestellung.id, produkt.id, produkt.name, bestellung.anzahl * produkt.preis as gesamtpreis format=commax10.2
   from order, produkt
   where bestellung.produktid = produkt.id;
quit;
nach oben
Druckversion | Anmelden oder registrieren um Kommentare einzutragen

Formatierung komplexer IF-Anweisungen

Eingetragen von StephanFrenzel. | 13 April, 2006 - 12:42

Ich bin immer wieder am kämpfen mit mir, wie komplexe, mehrzeilige IF-Anweisungen am besten zu formatieren sind.

Jetzt hab' ich gerade wieder so ein Monstrum vor mir:

if ( SALDO_1 > 0 or SALDO_2 > 0 or
     LIMIT_1 not in (., 0) or
     LIMIT_2 > 0 or LIMIT_3 > 0 or
     (DECKB_1 ^= 0 and DECKB_1 ^= .) or
     (DECKB_2 ^= 0 and DECKB_2 ^= . and
     (KDNRU1 ^= ' ' or KDNRU2 ^= ' ')
   ) ) then do;
   ...

Hin und wieder tendiere ich dazu, die ORs und ANDs an den Beginn von Zeilen zu stellen, um die logische Struktur deutlich werden zu lassen; das macht die Anweisung allerdings mehr als mehrzeilig, sprich: vielzeilig ;-)

if (     SALDO_1 > 0
     or  SALDO_2 > 0
     or  LIMIT_1 not in (., 0)
     or  LIMIT_2 > 0
     or  LIMIT_3 > 0
     or  (    DECKB_1 ^= 0
          and DECKB_1 ^= .
         )
     or  (    DECKB_2 ^= 0
          and DECKB_2 ^= .
          and (     KDNRU1 ^= ' '
                 or KDNRU2 ^= ' '
   )     )    )
   then do
;

Wird würdet ihr 's lösen?

P.S.: Eine Konvention zur Formattierung dieser Anweisung wäre im Ernstfall auf Where-Klauseln in SQL anwendbar.

» Anmelden oder registrieren um Kommentare einzutragen

Sieht doch "gut" aus ...

Eingetragen von HansKneilmann. | 13 April, 2006 - 12:52

... (meinte meine Kollegin)
Ich bin aber der gleichen Meinung!
Wir würden es fast genauso schreiben, ausser die drei Klammer-Zu am Schluß. Die würden wir "ordentlich" unter die jeweilige Klammer-Auf stellen. Also noch viel-zeiliger:

if (     SALDO_1 > 0
     or  SALDO_2 > 0
     or  LIMIT_1 not in (., 0)
     or  LIMIT_2 > 0
     or  LIMIT_3 > 0
     or  (    DECKB_1 ^= 0
          and DECKB_1 ^= .
         )
     or  (    DECKB_2 ^= 0
          and DECKB_2 ^= .
          and (     KDNRU1 ^= ' '
                 or KDNRU2 ^= ' '
              )
         )
   )
   then do
;
Wir werden nach lines of code bezahlt, Sie nicht .... ;-))

Gruß
Hans Kneilmann, Schäfer Shop GmbH (SSI)

» Anmelden oder registrieren um Kommentare einzutragen

Schade ...

Eingetragen von StephanFrenzel. | 13 April, 2006 - 14:02
( diese
  ( drei
    ( Klammern
) ) ) ...

... machen mir nämlich immer besonders viel Spaß, weil auf den ersten Blick klar zu sein scheint, welche Klammer welche schließt, sich die Sache in Wirklichkeit aber ganz anders verhält ... wie so viele Dinge, die scheinbar auf den ersten Blick klar sind ;-)

( Aber
  ( zur
    ( Regel
    )
  )
)

... sollte man solche Spielereien natürlich nicht erheben.

Gruß S.F.

» Anmelden oder registrieren um Kommentare einzutragen

Position abschliessendes Semikolon

Eingetragen von Jobst Heitzig. | 30 März, 2006 - 09:19

Klarer als

data staedte;
   length
      land   $ 30
      stadt  $ 30
      xkoord 8
      ykoord 8
   ;
run;
finde ich
data staedte;
   length
      land   $ 30
      stadt  $ 30
      xkoord 8
      ykoord 8
      ;
run;
oder sogar
data staedte;
   length
         land   $ 30
         stadt  $ 30
         xkoord 8
         ykoord 8
      ;
run;
So wird deutlicher, zu welcher Anweisung das Semikolon gehört.
Im Gegensatz zu Anweisungs-Paaren wie
do;
   ...
end;
die in der Regel mehrzeilige Blöcke bilden, ist dies bei Einzel-Anweisungen wie length ja die Ausnahme.

» Anmelden oder registrieren um Kommentare einzutragen

Position abschliessendes Semikolon

Eingetragen von HansKneilmann. | 30 März, 2006 - 09:42

Wir haben bei uns sehr gute Erfahrungen mit der Regel "Semikolon in der gleichen Spalte wie zugehöriger Befehls-Anfang" gemacht!
Also exakt die Variante 1 im Beitrag heitzig-j, 30 März, 2006 - 09:19.
Die Gründe sind genau die gleichen, die für die gleiche Spalten-Position von do; und end; sprechen.
Der Haupt-Grund für die o.g. Regel ist nicht "Schöhnheit", sondern "Nachprüfbarkeit".
Es ist einfach besser (im Sinne von "einfacher") die Gleichheit zweier Zeilen-Anfänge zu prüfen, als dabei noch einen "Versatz nach innen" zu berücksichtigen.
Die Gleichheit läßt sich mit Bleistift und Lineal auf dem Papier sauber prüfen (hier auch heute noch gemacht, habe ich vorige Woche bei "nicht-SAS"-Kollegen noch gesehen!) und unser Programmer's File Editor (pfe32.exe) behält die Spalte beim "Zeile-Runter" mit der Pfeil-Taste exakt bei, so dass man die Gleichheit auch im Editor papierlos prüfen kann... (das gleiche klappt im vi auf jeder UNIX-Kiste).

Die Regel "Semikolon in der gleichen Spalte wie zugehöriger Befehls-Anfang" wird dann richtig wichtig, wenn man anfängt Base-Code mit Makro-Code zu mischen, etwa so:

data staedte;
  set inDataSet;
  length
         land   $ 30
         stadt  $ 30
         /* checkDSV ist true wenn die DataSetVariable existiert */
         %if NOT %checkDSV(xkoord, inDataSet) %then %do;
           xkoord 8
         %end;
         ykoord 8
  ;
run;

Die Regel für Position abschliessendes Semikolon fehlt übrigends in obigem Beitrag "Anweisungen mehrzeilig" (AndreasMangold, 22 März, 2006 - 00:11)
Gruß Hans Kneilmann

P.S. Wieso ist das Color-Coding im Makro-then-Zweig unsauber (xkoord 8 rot statt schwarz) und nach dem Makro-end auch unsauber (ykoord 8 rot statt schwarz) ???

» Anmelden oder registrieren um Kommentare einzutragen

Kann man die Position des Semikolons offen lassen?

Eingetragen von AndreasMangold. | 9 April, 2006 - 21:13

Ich tendiere dazu, diese Regel so zu lassen, wie sie jetzt ist, also die Position des schließenden Semikolons in der Regel selbst nicht vorzuschreiben, die Beispiele aber so zu lassen.

Was die Farbgebung betrifft: das ist SAS. Besser kann es Redscope auch nicht.

» Anmelden oder registrieren um Kommentare einzutragen

Nicht übertreiben

Eingetragen von Jobst Heitzig. | 30 März, 2006 - 09:09

Grundsätzliche Zustimmung, aber: Aufpassen, dass der Code dadurch nicht zu "senkrecht" wird und man den Überblick über den Kontext verliert. Mitunter ist es also sinnvoller, zumindest kurze Listen von Objekten doch auf eine Zeile zu schreiben.

» Anmelden oder registrieren um Kommentare einzutragen

Komma-Position bei mehrzeiligen Anweisungen

Eingetragen von HansKneilmann. | 24 März, 2006 - 11:48

Volle Zustimmung zum obigen Beitrag "AndreasMangold, 22 März, 2006 - 00:11". Eine Ergänzung bzw. Verdeutlichung hätte ich:
Wichtig (und in den Beispielen enthalten) ist die Postition der Kommata in der Folgezeilen!
Regel: Jede Folgezeile wird mit dem Komma eingeleitet, im Gegensatz zur "normalen" Schreibweise in "normalen" Texten!
Das gilt z.B. für die Column-Liste in einem SQL-Select oder für die Parameter-Liste in einem Macro:

%mahn3( SGE=WP
      , VKORG=1030
      , VTWEG=                 /* alle VTWEGe */
      , MM_Info=no
      , JJ_Info=no
      , MManz = JA    /* der TABULATE ist ... */

      , atag_von=           /* leer=default */
    /*, atag_bis=20060228*/ /* 28.02.2006  =CEG-Start n... */
                            /* OHNE atab_bis, sonst fehlen ... */
      , atag_bis=           /* leer=default=keine ... */
      , kumvar=auft         /* auft=Kumulierung auf Auft... */
      , scorvar=CEG         /* leer=autom. CCN-/CEG-Scorewerte  */

    /*, tstinlib=dmworkOI*/
      );
Vorteil:
Man kann Parameter (=Zeilen) en bloc auskommentieren oder mit cut&paste rausnehmen bzw. einfügen, es passiert aber nix schlimmes, da das dazugehörige Komma automatisch mit "behandelt" wird.

» Anmelden oder registrieren um Kommentare einzutragen

guter Hinweis

Eingetragen von AndreasMangold. | 24 März, 2006 - 23:32

habe Ihre Vorschläge in diese Seite eingearbeitet.

» Anmelden oder registrieren um Kommentare einzutragen