|
|
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) |
Zeile 9: |
Zeile 9: |
| }} | | }} |
| | | |
− | == Rules? ==
| + | When program coding starts most programmers make a very personal but tremendously important decision. If not advised otherwise, an individual coding an algorithm or data processing workflow, in whatever language, will go for either '''''private efficiency''''' or '''''collaborative transparency.''''' Both alternatives may be as well appropriate in one working context and lead to extremely high cost in others. In this course we will refer to the results of this decision as ''"Implicit Coding"'' vs. ''"Explicit Coding"''. |
| | | |
− | While there is no technical reason to introduce and follow coding rules and typographical conventions, it has proven as helpful to do so depending on working context and purpose that is followed.
| + | * [[Implicit Coding (from Fraktal SAS Programming)|'''Implicit Coding''']] |
| + | * [[Explicit Coding (from Fraktal SAS Programming)|'''Explicit Coding''']] |
| | | |
− | '''''SAS is freedom''''' is good news for most ad-hoc programmers aiming to have results the same minute.
| + | It is important to state here that this distincition, whilest of some relevance, is not a predicate indicating the value of or justifying the budget for a specific programmer's work. Nevertheless, the decision between implicit vs. explicit coding needs to be done on a team lead or project responsible level, aware of possible consequences and agreed to as binding for all participants, e.g. team members, in a specific context. |
| | | |
− | '''''SAS is freedom''''' is bad news for all team leads and managers bearing responsibility for sustainable usage of resources and maintenance of programs written by individuals that will most likely leave some day.
| + | An inappropriate decision at this point may negatively affect product quality or overall cost. |
| | | |
− | Throughout the text of this tutorial we will therefore adhere to a set of rules that might seem superfluous at 1st sight but will help to catch structure and process implemented in a program without deep-diving into the code.
| + | '''Mixing both approaches is strongly not recommended.''' |
− | | |
− | | |
− | == Standards! ==
| |
− | | |
− | SAS supports modular coding very well because code processing follows a block or “group” structure as the architects at SAS Institute Inc. would put it. Let’s directly jump into this topic:
| |
− | | |
− | data basix;
| |
− | city='Washington'; lat="038° 054′ N"; long="077° 002′ W"; output;
| |
− | city='Berlin'; lat="052° 031′ N"; long="013° 024′ O"; output;
| |
− | city='Tokyo'; lat="035° 041′ N"; long="139° 046′ O"; output;
| |
− | proc sort; by lat;
| |
− | proc print; run;
| |
− | | |
− | This appears to be an easy to read and straightforward written program, and this is definitely true. And indeed, this code will complete without error messages and produce a formatted list of three cities along with their explicit latitude and longitude.
| |
− | | |
− | '''But this is not the program that is processed by SAS.'''
| |
− | | |
− | '''What does SAS see?'''
| |
− | | |
− | | |
− | == Groups ==
| |
− | | |
− | The SAS compiler processes the source code submitted in so called '''''steps''''' which in turn are comprised from groups of lines terminated by a semicolon. If users do not code full steps, then SAS completes the code up to a certain amount.
| |
− | | |
− | Lines terminated with semicolon are called '''''statements'''''.
| |
− | | |
− | Steps comprised from statements like above are called '''''run groups'''''.
| |
− | | |
− | Logically, the submitted code from the above example, will be transformed into three run groups that are executed in discrete steps. In each step syntax check and handling of user feedback is handled separately.
| |
− | | |
− | data basix;
| |
− | city='Washington'; lat="038° 054′ N"; long="077° 002′ W"; output;
| |
− | city='Berlin'; lat="052° 031′ N"; long="013° 024′ O"; output;
| |
− | city='Tokyo'; lat="035° 041′ N"; long="139° 046′ O"; output;
| |
− | run;
| |
− | | |
− | proc sort data=basix out=basix;
| |
− | by lat;
| |
− | run;
| |
− | | |
− | proc print data=basix;
| |
− | run;
| |
− | | |
− | | |
− | == Segments ==
| |
− | | |
− | As already emphasized, SAS coded workflow is processed as sequence of blocks or groups. Since this processing structure is used everywhere in SAS, we will refer to these blocks and groups as '''''segments''''' throughout the remainder of this text.
| |
− | | |
− | Due to various languages available inside SAS, particular segments might have their very special appearance. The '''''run group'' example''' from above is merely one of them.
| |
− | | |
− | '''Segments from different syntaxes may be hierarchically nested.'''
| |
− | | |
− | '''Segments may not intersect, with one exception, however.'''
| |
| | | |
| {{SeitenNavigation1 | | {{SeitenNavigation1 |
When program coding starts most programmers make a very personal but tremendously important decision. If not advised otherwise, an individual coding an algorithm or data processing workflow, in whatever language, will go for either private efficiency or collaborative transparency. Both alternatives may be as well appropriate in one working context and lead to extremely high cost in others. In this course we will refer to the results of this decision as "Implicit Coding" vs. "Explicit Coding".
It is important to state here that this distincition, whilest of some relevance, is not a predicate indicating the value of or justifying the budget for a specific programmer's work. Nevertheless, the decision between implicit vs. explicit coding needs to be done on a team lead or project responsible level, aware of possible consequences and agreed to as binding for all participants, e.g. team members, in a specific context.
An inappropriate decision at this point may negatively affect product quality or overall cost.
Mixing both approaches is strongly not recommended.