Author: Kurt_Bremser
Original Post: https://communities.sas.com/t5/SAS-Communities-Library/Maxims-of-Maximally-Efficient-SAS-Programmers...
최고의 효율성을 자랑하는 SAS 프로그래머를 위한 격언
최근에 http://www.schlockmercenary.com/에서 70명의 격언 ally Effective Mercenaries에 대한 숨겨지지 않은 참조를 포함하는 저의 포스팅 중 하나와 관련된 농담을 덧붙였습니다. 이로 인해 @ballardw로부터 질문을 받게 되었고, 본격적으로 프로젝트를 시작하기로 결정했습니다. 이것은 New Hacker 's Dictionary 및 유사한 작업의 전통에서 지속적인 작업으로 계획되어 있으므로 새로운 격언에 대한 제안이나 이미 존재하는 격언의 향상에 대해 언제든지 편하게 연락해주시면 감사하겠습니다. 가공하는 것은 허용되나, 향후 다른 곳에서 격언이 사용된다면 그 수를 고정하려고 합니다.
격언 1
설명서를 읽어라
SAS는 제품과 관련된 훌륭한 설명서를 제공합니다. 설명서 내용을 제대로 파악하시면 문제 해결 능력이 월등히 향상됩니다.
격언 2
로그를 읽어라
프로그램에 대해 알아야 할 모든 것이 로그에 있습니다. 오류를 찾으려면 메시지와 참고를 해석하는 것이 필수입니다.
격언 3
데이터를 알라
변수 유형, 길이, 형식 및 내용 등 데이터 구조를 명확히 파악한다면 더욱 신속하게 문제를 해결할 수 있습니다. 데이터 세트 속성의 "열"섹션을 살펴보면 간단히 수 많은 문제를 해결할 수 있습니다. proc 내용을 자주 사용하시기 바랍니다.
격언 4
확실하지 않은 경우 테스트 실행을 수행하고 결과를 확인하라. 의구심이 든다면 계속해서 물어라
SAS의 핵심은 통역 언어입니다. 몇 번의 마우스 클릭만으로 한 단계를 실행할 수 있습니다.
"시도 해봐." (Grace Hopper, 제독, 미 해군)
격언 5
질문하라 그곳에 답이 있을 것이다
SAS 기술 지원 및 SAS 사용자 커뮤니티를 통해 도움을 얻으실 수 있습니다. 명확한 질문, 예제 데이터, 코드 (로그 포함 또는 내부, 격언 2 참조) 및 실패한 위치를 정확히 언급하신다면 더욱 좋습니다.
격언 6
Google을 가까이 두어라
오류 메시지 또는 문제가 되는 텍스트 앞에 SAS를 넣어 검색하면, 대개 첫 번째 결과 페이지에서 문제를 해결하기위한 힌트가있는 리소스가 나타납니다. 다른 검색 엔진에서도 마찬가지입니다.
격언 7
절차를 명심하라
(예외는 규칙을 증명합니다)
작업을 해결하기 위해 절차를 사용하는 방법을 배웁니다. 5 줄의 proc means는 데이터 단계 로직의 20 줄 혹은 그이상에 상응 할 수 있습니다.
격언 8
형식을 명심하라
(예외는 규칙을 증명합니다)
격언 7과 마찬가지로 SAS는 입력 및 출력을 위한 다양한 형식을 제공합니다. 이러한 기능을 활용하여 필요한 것이 존재 하지 않는 경우, 일반적으로 복잡한 데이터 단계를 필요로 할 수 있습니다.
격언 9
함수를 명심하라
(예외는 규칙을 증명합니다)
2019-01-31 현재 documentation.sas.com에는 649 개의 데이터 단계 함수 및 호출 루틴이 게시되어 있습니다. 문제를 더 쉽게 해결하거나 모두 해결하는 기능을 찾을 못 찾는 일은 거의 드뭅니다.
격언 10
SQL은 비효율적일 수 있다
대규모 데이터 세트의 경우 proc sql이 조인을 처리하는 방식은 대규모 유틸리티 파일에 대한 많은 무작위 액세스를 통해 생성됩니다. 이는 데이터 단계 및 필요한 proc 정렬 단계로 수행된 조인보다 훨씬 덜 효율적일 수 있습니다.
격언 11
매크로는 잊어라
(예외는 규칙을 증명합니다)
그룹별 처리를 통해 트릭을 수행 할 수 있게 되면 더이상 코드를 반복 할 필요가 없습니다. 매크로 언어는 날짜 계산과 같은 데이터 처리를 위한 것이 아니라 동적 코드를 만드는데도 사용됩니다. 매크로 변수에 목록을 만드는 대신 데이터 세트에 저장하여 호출을 실행하면 됩니다. 데이터 단계에서 계산을 수행하고 결과를 symput으로 매크로 변수에 저장합니다.
매크로는 Base SAS 코드로 해결할 수 없는 것을 마찬가지로 해결할 수 없습니다. 그러나 코드를 작성하는 데 필요한 노력을 줄일 수는 있으며 코드를 데이터 기반으로 만드는 데 도움이 될 수 있습니다. 실행 호출에 대해서는 격언 33를 참고하시기 바랍니다.
격언 12
깔끔하게 만들어라
적절한 시각적으로 잘 정돈된 서식은 더 나은 코드를 만듭니다. 의미 블록을 표시하려면 들여쓰기를 사용하시기 바랍니다. 동일한 논리 수준에 있는 항목은 동일한 열에 있어야 합니다.
지나치게 긴 줄을 피하고 필요한 경우 줄 블록을 만드시는 것을 추천합니다. 과거 80자 글자수 제한 등 또한 좋은 방법입니다.
일관성을 유지해야 합니다. 다음 코드 담당자는 마치 5 살 짜리 어린이처럼 느껴지는 본인 일 수 있습니다. 되도록 간결하게 일관성을 유지하시기 바랍니다.
더불어 주석을 자주 사용하는 것을 권장합니다.
격언 13
공부가 끝났다면, 본인의 인생도 끝난 것이다
(Will Rogers, John Wooden)
배우고자 하는 의지를 가지고 있는 한 항상 더 발전할 것입니다. 더 이상 배우지 않는다면 악취가 나는 고인물이 될 수 있습니다. 공부할 시간이 없다는 말은 핑계가 될 수 없습니다. 지식은 무한합니다.
"저는 선생님들로부터, 동료들로부터 많은 것을 배웠지만 대부분은 제 학생들로부터 배웠습니다." - 탈무드
격언 14
올바른 도구를 사용하라
“작업을 수행하기 위해서는 올바른 도구만이 답입니다."
(Montgomery Scott, Captain, Starfleet)
간단한 "XYZ 사용"또는 "XYZ 사용 안 함” 등과 같은 단순한 명령문으로 자신의 능력에 한계치를 두지 마시기 바랍니다. 특정 방법으로 문제 해결 능력이 향상된다면 앞으로 그 방법을 활용하시기 바랍니다. 아직 모르는 것이 있다면 배우려는 자세를 가져야 합니다. (격언 13 참조) 타사 도구가 더 적합하다면 이 또한 사용합니다. 예를 들어 DBMS 작업은 DB 자체에서 수행해야 합니다. 운영 체제 관련 문제는는 운영 체제에 맡겨야 합니다. (격언 15 참조)
격언 15
홈그라운드와 친숙해져라
SAS가 구현된 환경에 대한 지식을 보유해야 합니다. 시스템의 레이아웃, 기본 구문 및 가장 중요한 유틸리티를 알고 있어야 합니다. 특히 UNIX는 당신의 삶을 더 쉽게 만들어 줄 도구가 풍부합니다. 시스템한테 지배 당하는 것이 아닌 시스템을 지배해야 합니다.
격언 16
제대로 작성되지 않았다면, 괜한 기대는 하지 말아라
제대로 문서화 되지 않은 코딩은 존재할 수 없습니다. 순간 괜찮아 보일지라도, 문서화되지 않은 프로그램, 데이터, 프로세스 등을 처리해야 하는 순간은 마치 처음부터 시작하는 것과 같습니다. Jedi 프로그래머는 문서화와 문서 읽기에 업무시간의 90 %를 씁니다.
“나는 그것을 적어야했다. -Dilbert”
Scott Adams
격언 17
SAS를 따르라
데이터웨어 하우스는 데이터베이스와 다른 구조가 필요하며 스프레드시트와 다른 구조가 필요하기도 합니다. DBMS디자인과 데이터웨어 하우징 내의 테이블차이와 스프레드시트와 SAS테이블 내의 셀 차이를 구분해 사용해야 합니다. SAS 테이블을 중점으로 분석 요구 사항에 따라 모델링합니다.
격언 18
고유한 명칭을 사용하라
미리 정의된 SAS 함수의 이름을 사용하거나 변수, 데이터 세트 등과 같은 개체에 대한 루틴 또는 형식을 호출하는 것은 위험합니다. 이러한 방법은 혼선을 빚어 단순한 오타에서도 추적하기 어려운 문제로 만들게 합니다.
격언 19
긴 호흡을 가져라
(데이터를 구조로 유지하지 마십시오)
스프레드시트를 활용하는 사용자는 데이터를 나란히 정렬하여 날짜, 카테고리 등의 항목을 첫 번째 열에 삽입하는 경향이 있습니다.이는 그룹 처리를 위해 SAS에서 사용할 수 있는 모든 방법에 반대로 실행되며, 변수 열 이름이 있거나 정렬되어 있는 경우, 전혀 필요하지 않은 매크로 및 호출 실행 사용 등과 같은 동적 코드 생성에 의존해야 하기 때문에 프로그래밍을 어렵게 만듭니다. 회귀 분석을 위해 데이터를 준비 할 때와 같이 광범위한 형식이 필요한 경우가 있습니다. 그러나 데이터 처리 및 저장을 위해 항상 긴 형식이 필요합니다.
동적 변수 이름은 불필요한 동적 코드를 수행하도록 합니다.
격언 20
명칭을 간결히 하라
짧고 간결한 변수 이름을 사용하면 오타 위험을 줄이고 더 빠르게 입력 할 수 있으며 코드를 더 쉽게 읽을 수 있습니다. 레이블에 추가 정보를 입력해야 합니다.
격언 21
비트 조인을 형식화하라
데이터 세트에서 형식을 생성하면 한 번의 순차 패스로 다른 데이터 세트에서 조인을 수행 할 수 있습니다. 형식이 메모리에 타당한 경우 큰 데이터 세트를 피할 수 있도록 쉽게 이해할 만한 수단을 제공합니다.
격언 22
올바른 데이터를 활용하라
외부 소스에서 불러 올때 단순히 proc 가져오기에 의존하는 것은 위험합니다. 입력 데이터에서 예기치 않은 일이 생길 경우, 오류로 인해 실패한 데이터 단계를 활용해야 합니다. 이를 통해 분석 체인 오류를 초기에 감지 할 수 있습니다. 격언 22는 많은 자동화 기능으로 인해 데이터 활용에 Excel 파일 형식을 사용하는 것을 특별히 배제하는 것을 추천합니다.
격언 23
재귀
격언 23을 참조하시기 바랍니다.
격언 24
0으로 돌아가라
0이 아닌 리턴 코드로 성공적인 실행을 종료하는 배치 프로그램은 허용되지 않습니다 . 경고 없음, 오류 없음. 예상치 못한 이벤트 등은 0이 아닌 리턴코드를 유발하므로 가능한 한 빨리 작업이 중단됩니다.
격언 25
심플한 로그를 작성하라
생산 레벨의 프로세스 로그에는 불필요한 NOTE가 존재해서는 안됩니다. 자동 유형 변환, 누락 된 값 등이 그 예시입니다.
이를 통해 의미상의 문제나 부정확한 데이터를 쉽게 감지 할 수 있게 되는데, 이는 종종 예상치 못한 NOTE를 유발하기 때문입니다.
로그의 일부가 불분명한 경우,이후의 모든 오류 또는 기타 문제가 이로 인해 발생할 수 있으며 대부분의 경우 큰 문제가 되지는 않습니다. 처음부터 끝까지 디버그 해야 할 뿐이죠.
격언 26
. sas를 카탈로그보다 우선시 해라
카탈로그에 코드를 보관할 수 있지만 간단히 텍스트 파일에 저장하는 것이 좋습니다. SAS 카탈로그는 SAS 버전 및 운영 체제 환경에 따라 상이합니다. 텍스트 파일은 버전이나 운영 체제별로 다르지 않으며, 코드 페이지의 최종 변경은 IOM 브리지를 통해 SAS 자체 또는 파일 전송 유틸리티에 의해 처리됩니다.
텍스트 파일을 사용하는 경우 텍스트 처리를 위해 rep, awk , sed 등의 외부 도구를 사용할 수도 있습니다.
같은 맥락에서 항상 proc 형식 및 관련 cntlin 데이터 세트 코드를 저장해서 사용하는 카탈로그 내 생성된 형식에 의존하는 것은 추천하지 않습니다.
격언 27
텍스트 규칙
가능하면 일반 텍스트를 사용하는 것이 좋습니다. 데이터 전송을 위해 간단한 파일 형식을 사용하는 경우, 텍스트 편집기로 데이터를 검사 할 수 있습니다. xlsx 와 같이 압축 된 경우에도 이전 바이너리 형식보다 최신이며 XML 또는 JSON 기반의 파일을 선호합니다. 코드를. sas 파일에 저장하여, 개발 중 Enterprise Guide 프로젝트를 임시 저장소로 사용하시기 바랍니다. 텍스트는 프로그래머에게 도움이 되는 버전 관리 및 기타 도구에 적합한 반면에 바이너리 파일은 그렇지 않은 경향이 있습니다. 격언 26을 참조하시기 바랍니다.
격언 28
매크로 변수에는 형식이 필요없다
'01 jan1960'd와 0은 SAS 코드에서 동일한 값을 나타냅니다. 따라서 매크로 변수의 형식은 제목과 같이 특수한 경우가 아니면 필요하지 않습니다. 조건을 위해 사용해야 하는 경우, 원시 값으로 충분하며 쉽게 만들 수 있습니다.
격언 29
의심이 될 땐, 무차별 대입하라
(Ken Thompson)
간단하고 이해하기 쉬운 코드를 사용하시기 바랍니다. 상황이 불가피한 경우에만 스마트한 알고리즘을 활용합니다. 이 또한 KISS (Keep It Simple, Stupid) 원칙의 또다른 형태입니다.
격언 30
분석해라, 그리고 최적화 해라
병목현상을 정확히 파악하기 전에는 최적화 해서는 안됩니다. 1 초 밖에 걸리지 않는 일을 굳이 먼저 할 필요가 없습니다. 가능한 코드를 단순하게 유지해야 합니다. 또한 격언 29을 참조하시기 바랍니다.
"조기 최적화는 모든 악의 근원"
(예: C.A.R Hoare)
격언 31
컴퓨터는 멍청하다
당신이 의도한 일을 소프트웨어가 직접 할거라는 착각을 버려야 합니다. 특정 순서가 필요한 경우 SQL에서 "order by"를 정렬하거나 사용해야 합니다. 변수가 특정 길이여야 하는 경우 별도로 설정해야 합니다. proc 불러 오기 추측에 의존하지 말고, 자신의 데이터 단계를 살펴보아햐 합니다. (격언 22 참조) 지금 당장 자체적으로 특정 방식으로 작동하더라도, 미래에 대해서는 보장할 수 없습니다. 새로운 소프트웨어 릴리스 또는 데이터 변경으로 인해 프로세스가 정상적으로 작동하지 않을 수 있습니다. 항상 유념해야 합니다.
격언 32
COMPARE 없이는 테스트는 꿈도 꾸지 마라
기존 코드를 변경할 때 PROC COMPARE를 사용하여 이전 버전의 데이터에 대해 회귀 테스트를 실행하지 않고 릴리스하는 행동을 지양해야 합니다. 이러한 방식은 원하는 변경 사항에 대해서만 적용되거나 또는 최적화의 경우 변경 사항이 전혀 없을 수도 있습니다. 개발 프로세스의 중요한 단계에서 COMPARE를 사용하여 나중에 해당 지점을 검색 할 필요 없이, 에러가 발생할 시 바로 확인할 수 있습니다. COMPARE에 상당한 시간이 소요된다면 커피 한 잔의 여유를 갖기를 바랍니다. 분명 가치가 있는 시간입니다.
격언 33
지능형 데이터가 지능형 프로그램을 만든다
Jedi 프로그래머는 지능형 데이터 구조를 위해 노력합니다. 이러한 경우 코드는 자체적으로 지능적이고 잘 설계됩니다.
"나쁜 프로그래머는 코드에 대해 걱정합니다. 좋은 프로그래머는 데이터 구조와 그 관계에 대해 걱정합니다."
(Linus Torvalds)
시간 관련 데이터를 처리 할 때 SAS 날짜 및 시간값을 활용하시기 바랍니다. 카테고리는 문자 변수로 유지하는 것이 가장 좋습니다. DB 시스템의 도메인 테이블 등 형식 생성을 자동화하는 것이 적절합니다. select ( ) 블록 또는 if-then-else 명령문 대신 이러한 형식 사용을 권장합니다. 격언 8을 참조 하시기 바랍니다. 제어 데이터 세트를 작성하고 call execute를 사용하여 동적으로 코드를 작성하시기 바랍니다. 특히 비 ASCII 리터럴을 데이터에 삽입하고 코드에서 제외합니다. 이러한 과정을 통해 코드의 시스템간 이동 시 별다른 문제가 발생하지 않습니다.
순서가 중요한 경우에는 날짜 형식이 적절히 구조화된 방식을 택하시기 바랍니다. (MMDDYY 대신 YYMMDD).
격언 19 또한 참조하시기 바랍니다.
격언 34
순차적으로 작업하라
한 번에 모든 것이 마법처럼 이루어지기를 바라는 것은 신기루와 같습니다. 중간 데이터 세트 및 결과를 생성하여 각 단계에서 해결이 가능한 문제를 하나씩 해결합니다. (격언 29 참조).
같은 맥락에서 단순 반복으로 프로그램에 여러 변경 사항을 적용하는 것 또한 지양하는 것이 좋습니다. 대신 모든 논리적 변동사항에 대해 항상 유의하시기 바랍니다. 이를 통해 모든 변경 사항에 대한 회귀 테스트가 가능하며, 회귀 테스트 중 다소 명확하지 않은 문제가 발생하면 뒤로 돌아가 버그의 원인이 되는 변경 사항을 찾는 것이 더 쉽습니다.
격언 35
두 가지 어리석음
# 1 "이건 오래된 방법이니 당연히 훌륭하겠지?"
# 2 "이건 최신 유형이니 더 낫겠지?"
유행의 흐름은 가변적이며, 절대 불변의 숨겨진 보석이 있을 수도 있습니다. 항상 열린 마음을 가지고 작업해야 합니다.
격언 36
최종 테스트는 끝이 아니다
모든 작업의 마무리 단계에는 동일한 서버, 동일한 사용자, 동일한 배치 스크립트 등과 같은 동일 환경 내 프로그램 테스트가 이루어져야 합니다. 그렇지 않으면 상용화 즉시 지원 요청이 빗발칠 수 있습니다. 일반사용자는 개발자보다 제한된 환경일 수 있으므로 코드를 개발할 때 이를 염두에 두시기 바랍니다.
격언 37
완벽함
완벽함이란 추가할 대상이 더 이상 존재하지 않는 것이 아니라, 더 이상 제거해야 할 것이 없을 때를 뜻합니다.
(Antoine de Saint-Exupery)
KISS 원칙 적용- 또한 프로그래밍에 적용되는 " muntzing " 관행을 유념하시기 바랍니다.
불필요한 코드, 중복 변수, 관련 없는 데이터를 삭제해야 합니다.
"완벽함이 비록 불가능할지라도, 완벽함을 추구한다면 탁월함을 얻을 수 있습니다."
(Vince Lombardi)
격언 38
두려워하라
머피의 법칙과 같은 일이 발생할 수 있습니다.
" 예견된 불행은 일어날 수 밖에 없다."
이러한 관점을 통해 코드를 작성하고 예상치 못한 상황에 대비해 안전 장치를 마련해야 합니다.
예상치 못한 상황이 발생할 때, 알람 설정이 되어 있는지 확인합니다. 예: 잘못된 데이터에서 일괄 프로그램 충돌을 일으켜 스케줄러가 에러를 포착 (Larry Niven)
격언 39
프로그래머 또한 사람이다
.
인간은 누구나 실수를 합니다. 누군가가 당장 5 분 후에 당신을 비판할 수도 있으며, 이를 너그러이 용인할 수 있어야 합니다. 선호도와 수준은 어디에든 존재합니다. 지금 현재의 상태가 최악은 아니지만 그렇다고 해서 확실히 최고가 아닐 수 있습니다. 모든 상황에서 교훈을 얻으시기 바랍니다.
더불어 코드는 코더가 아닙니다. 성인군자라도 믿기 어려운 코드를 생성할 수 있으며, 그 반대도 마찬가지입니다.
격언 40
고객과 소통하라
최종 데이터 소비자와 원활한 의사소통을 하는 것은 필수입니다. 모호하거나, 과도한 기술 용어는 배제하여 소비자가 원하는 방향으로 지원해야 합니다.
고객과의 소통 자체부터 문제 해결에 큰 진전을 불러오기도 합니다..
프로그래머의 섣부른 판단이 아닌 고객이 원하는 것을 정확히 파악해야 합니다. 예시를 빈번히 그리고 최대한 빠른 시일 내에 전달하기를 권장합니다.
격언 41
지혜는 경험에서 나온다
불행히도 대부분은 어리석은 경험을 통해 깨달음을 얻습니다.
격언 42
답이 아니라 질문이다
적절한 질문은 바른 길로 안내합니다. 잘못된 질문에는 격언 42번을 다시 한 번 참고하시기 바랍니다.
격언 43
최종 목표
특정 정보가 필요한 범위는 어디까지 인가? 이 질문에 대한 답은 도구와 방법의 선택을 필요로 할 것입니다. 정보는 작업의 핵심이며, 정확하면서도 시기적절하게 전달하는 것이 궁극적인 목표입니다.
콘텐츠가 수락된다면 가장 아름다운 결과일 것입니다.
이 모든 것은 요구 사항이 정교하고 명확하게 적용되었음을 의미합니다. (격언 42 참조)
코드를 증명할 수 있는 테스트 케이스를 정의하시기 바랍니다.
격언 44
띄어쓰기를 없애라
모든 운영 체제 및 프로그래밍 언어는 이름과 개체의 주요 구분 기호로 공백을 사용합니다. 따라서 파일, 디렉토리, 열 등의 이름에 공백 사용을 지양해야 합니다. UNIX 및 Windows에서는 파일 이름을 따옴표로, SAS 에서는 'my name'n 구문으로 특정 환경에서 띄어쓰기가 가능하더라도 가급적이면 사용하지 않는 것이 좋습니다. 밑줄로도 동일한 의미를 전달할 수 있으며, 이러한 이름을 훨씬 쉽게 처리 할 수 있습니다.
(특정 제품이 파일 및 경로 이름에 공백을 기꺼이 사용한다는 사실은 이러한 관행을 받아들여야 한다는 것이 아닙니다. 일부의 무지함을 보여주는 예시입니다.)
격언 45
TANSTAAFL
세상에 공짜 점심은 없다.
이 영원한 진리를 깨우친 위대한 Robert A. Heinlein에게 경의를 표합니다.
훌륭하고 내구성이 뛰어난 코드는 생각과 노력이 필요합니다. 둘 중 하나라도 간과해서는 안됩니다. 오. 모든 가치를 돈으로 환산 할 수는 없지만, 가치 있는 모든 것은 가격을 따릅니다.
"빠르다. 싸다. 좋다. 아무 거나 두 개를 고르세요."
격언 46
숨겨진 공백을 유의하라
문자 변수의 길이가 고정되어 있고 값은 항상 해당 길이까지 공백으로 채워져야 한다다는 사실을 간과하는 경향이 있습니다. 따라서 비교 혹은 연결을 위해 항상 trim ( ) 을 사용하는 것이 좋습니다 .
예:
| if charvar in ('AAA','BBB','CCC'); |
상단의 예시의 경우 정의에 의한 charvar의 길이가 3을 초과하더라도 잘 작동할 것이지만,
| if findw('AAA BBB CCC',charvar) > 0; |
charvar 의 길이가 5이고 따라서 비교 문자열에서 찾을 수 없는 'AAA'를 포함하는 경우 작동하지 않습니다. 마찬가지로 charvar = charvar !! ' some_other_string '; 등과 관련하여 미숙한 초보 프로그래머의 경우 당황할 수 있습니다.
격언 47
길이를 설정하라
새 문자 변수를 만들 때 항상 명시적으로 충분한 길이를 설정하도록 합니다. 문자 변수에 리터럴이 할당되면 긴 데이터가 잘릴 가능성이 있으며 향후에 혼란을 야기할 수 있으므로 첫 번째 assigment를 통해 길이를 설정합니다.
예시:
|
flag = 'no';
if (condition) then flag = 'yes';
if flag = 'yes' then …;
|
격언 48
점, 점, 항상 구둣점을 조심하라
항상 마침표로 매크로 변수 참조를 종료하는 습관을 만드시기 바랍니다. 마침표의 존재가 부재보다 큰 이점이며, 이는 마침표를 생략하게 되는 경우 예상치 못한 결과를 초래하고 혼란을 빚을 수 있습니다.
| libname myexcel xlsx "/path/excelfile&year.xlsx"; |
격언 49
반드시 실행해 보라
실행의 중요성을 간과하는 사람들이 더러 있습니다. SAS가 이를 자체적으로 처리하기 때문입니다. 그러나 때로 시스템이 감지하기 어려운 문제 발생 상황이 존재합니다. 매크로의 다음 부분을 상상해 보시기 바랍니다.
|
data _null_;
call symputx('nobs',nobs);
set have nobs=nobs;
%do i = 1 %to &nobs;
|
실행하지 않아 데이터 단계가 아직 컴파일 및 실행되지 않으며 기호 참조가 해결되지 않음이라는 오류가 발생했습니다.
결론: 매크로 변수 참조의 점과 마찬가지로 실행해보는 것은 그만한 가치가 있으며, 그렇지 않은 경우 댓가를 치를 수 있습니다.
격언 50
OBS = 시스템 옵션을 재차 확인하라
종종 OBS =는 테스트에 대한 관찰 수를 제한하도록 설정되었습니다. 이로 인해 나중에 설명 할 수 없는 것처럼 보여 예기치 못한 종료를 불러올 수 있습니다.
격언 51
해시를 다뤄라
최근에 도입된 버전 9 해시는 복잡한 프로그래밍이 필요했던 난해한 문제를 해결하거나 시간과 디스크 공간을 소비하는 다단계 작업을 해결하는 데 도움이 되는 인-메모리 찾기를 위한 고성능 도구를 제공합니다.
기본 작동법을 터득하여, 중요한 순간에 이를 사용하는 것은 SAS 프로그래머에게 필수입니다.
Michele M. Burlew의 SAS® Hash Object Programming Made Easy에서 자세한 내용을 찾아보실 수 있습니다.
격언 52
휴식을 취해라
절대 불가능해 보이는 문제에 부딪힐 때마다 잠시 멀어져 휴식을 취하시길 바랍니다. 게임 또는 게임을 시청을 하고, 음악을 듣거나 S.O.와 대화를 나누기도 하고, 훌륭한 식사를 하거나, 향긋한 커피를 마시도록 합니다. 또한 밤에는 잠을 자도록 합니다.
불필요하거나 관련이 없는 생각에서 벗어나게 되면, 새로운 마음가짐으로 재도전 할 수 있게 될 것입니다. 종종 꿈속에서 해결책이 떠오르는 경우도 있습니다. 바로 저의 경험이며, 한밤 중에 일어나서 메모를 하여, 사무실에 도착한지 몇 분 만에 문제를 해결할 수 있었습니다.
