아직도 use strict/use warnings를 전혀 쓰지 않는 나쁜 버릇이 있다. 20년 전에 대충 독학으로 익힌 펄 실력이니 오죽하겠는가.
strict는 펄에서 사용하는 'pragma'이다. 이것은 컴퍼일러(펄에서는 인터프리터라고 하는 것이 더욱 정확할 것이다)에게 어떤 일을 하라고 지시하는 전처리명령이라고 한다. strict pragma는 비정상적인 동작을 유발하거나 디버그하기 어려운 상황을 에러로 전환해 준다. 다음의 코드를 보자.
$ cat test.pl #!/usr/bin/perl # use strict; $var = 1; my $VAR = 2; $ perl test.pl Global symbol "$var" requires explicit package name (did you forget to declare "my $var"?) at test.pl line 5. Execution of test.pl aborted due to compilation errors.
만약 use strict를 선언하지 않았다면 이 코드를 실행할 때 아무런 에러가 발생하지 않았을 것이다. Package name을 명시적으로 선언하지 않았다는 에러 메시지가 나온다. 패키지라고 하면 코드나 라이브러리의 '묶음' 또는 '배포 단위'를 떠올리기 쉬운데, 여기에서는 그것을 의미하는 것이 아니다.
변수의 활동 영역은 네임스페이스이고, 이들 사이의 전환을 가능하게 하는 키워드가 패키지라고 이해하면 될까? 패키지 키워드를 사용하지 않았다면, 기본 네임스페이스는 main이다.
$ cat test.pl #!/usr/bin/perl use strict; $main::x = 42; my $x = 13; print "$x\n"; print "$main::x\n"; $ perl test.pl 13 42
위의 사례에서 $main::x(package variable)과 $x(lexical variable)은 완전히 다르다.
쓰기 위해서 안전하게 파일을 여는 방법에도 익숙해져야 한다.
[Modern Perl Programming] Thre-arg open() (Migrating to Modern Perl)
펄 5.010 이후부터 등장한 say() 함수도 종종 써야 되겠고... Modern Perl 문서를 프린트해 놓은 것이 있는데 어디에 있는지를 모르겠다. 인터넷에서 PDF 파일을 찾아서 다운로드해 두었다. O'Reilly에서 발간한 펄 관련 서적의 PDF가 종종 인터넷에 그대로 공개된 사연은 무엇일까? 이 회사의 Open Books Project 웹사이트를 가 보아도 펄 관련 서적은 보이지 않는다. 아무튼 고마운 일이다. 공개 라이선스의 여러 형태에 대하여 공부할 필요성을 느낀다.
좋은 펄 코딩 습관을 들이기로 마음을 먹은 후 처음 작성한 짧은 코드는 POCP(percentage of conserved sequences)를 계산하는 쉘 스크립트의 wrapper였다. 그런데 shell의 올바른 국문 표기는 '쉘'인가, 혹은 '셀'인가? 검색 결과는 후자가 맞다고 한다.
POCP는 미생물 균주가 동일 속(genus)에 속하는지를 판별하는 지표로 제안된 것이다. 이에 대해서는 2019년에 블로그에 글을 쓴 일이 있다(링크). 원본 스크립트인 POCP.sh는 오직 한 쌍의 유전체(정확하게는 아미노산 서열 집합)만을 받아들인다. 따라서 10개 정도의 데이터를 처리하려면 두 유전체의 가능한 모든 조합을 만들어서 POCP.sh에 제공해야 된다.
하나의 디렉토리에 모든 유전체 파일을 복사해 넣은 다음, 펄 모듈 Math::Combinatorics을 사용하여 모든 조합을 구성한 다음 POCP.sh에게 인수로 제공하는 간단한 펄 스크립트를 만들어 보았다. 현대적인 펄 코드 작성 스타일을 따르기 위해 노력을 한 것은 물론이다.
좀 있어 보이는 펄 코드를 짜려면 명령행 인수를 잘 처리해야 하고, 도움말 메시지를 보여주는 친절도 베풀어야 한다. 이에 대해서는 다음 웹사이트를 참고하도록 하자. 대단히 간결하면서도 유용하다.
[Perl.com] Professional scripts are a snag with Getopt::Long
댓글 없음:
댓글 쓰기