펄 모듈 스타일 가이드

펄 모듈 스타일 가이드 (perlmodstyle)

Perl 모듈을 작성할 때 커뮤니티의 "모범 사례"가 무엇인지 정리한 문서예요. perlstyle의 권장 사항을 확장한 것이므로, 이 문서를 읽기 전에 perlstyle을 먼저 읽어 보시길 권해요. 특히 CPAN에 모듈을 공개하려는 저자에게 유용해요.

출처: perlmodstyle - Perl module style guide

소개 (INTRODUCTION)

이 문서는 Perl 모듈 작성에 관한 Perl 커뮤니티의 "모범 사례"를 설명하려고 해요. 이 문서를 읽기 전에 필수 독서로 여겨지는 perlstyle의 권장 사항을 확장해요.

이 문서는 모든 모듈 저자에게 유용하도록 의도되었지만, 특히 CPAN에 모듈을 공개하고 싶은 저자를 대상으로 해요.

초점은 모듈의 개발자만 보는 부분이 아니라, 모듈 사용자에게 보이는 스타일 요소에 있어요. 하지만 이 문서의 많은 지침은 모듈 내부에도 확장 적용할 수 있어요.

이 문서는 perlnewmod와 다른 점이 있어요. 새 모듈 만들기 튜토리얼이 아니라 스타일 가이드라는 점이죠. 모듈이 모범 사례에 부합하는지 비교할 수 있는 체크리스트를 제공하고, 이를 달성하는 방법을 자세히 설명하지는 않아요.

이 문서의 모든 조언은 경험 많은 CPAN 저자와 사용자와의 광범위한 대화에서 얻은 것이에요. 여기 주어진 모든 조언은 이전 실수의 결과예요. 이 정보는 여러분이 같은 실수와, 그 실수를 고치는 데 필연적으로 필요한 추가 작업을 피할 수 있게 돕기 위한 것이에요.

이 문서의 첫 번째 섹션은 항목화된 체크리스트를 제공하고, 이후 섹션은 목록의 항목에 대해 더 자세히 논의해요. 마지막 섹션 "Common Pitfalls"는 CPAN 저자가 저지르는 가장 흔한 실수 몇 가지를 설명해요.

빠른 체크리스트 (QUICK CHECKLIST)

이 체크리스트의 각 항목에 대한 자세한 내용은 아래를 보세요.

시작하기 전에 (Before you start)

바퀴를 다시 발명하지 마세요
가능하면 기존 모듈을 패치, 확장하거나 서브클래싱하세요
한 가지 일을 하고 그것을 잘 하세요
적절한 이름을 선택하세요
공개하기 전에 피드백을 받으세요

API

API는 평균적인 프로그래머가 이해할 수 있어야 해요
간단한 작업에는 간단한 메서드를
기능과 출력을 분리하세요
서브루틴이나 메서드 이름을 일관되게 지으세요
매개변수가 두 개보다 많을 때는 명명된 매개변수(해시 또는 해시레프)를 사용하세요

안정성 (Stability)

모듈이 use strict와 -w 아래에서 동작하는지 확인하세요
안정적인 모듈은 하위 호환성을 유지해야 해요

문서화 (Documentation)

문서를 POD로 작성하세요
목적, 범위, 대상 애플리케이션을 문서화하세요
매개변수와 반환 값을 포함해 공개적으로 접근 가능한 각 메서드나 서브루틴을 문서화하세요
문서에 사용 예제를 제공하세요
README 파일과 어쩌면 릴리스 노트, 변경로그 등을 제공하세요
추가 정보에 대한 링크를 제공하세요 (URL, 이메일)

릴리스 고려사항 (Release considerations)

Makefile.PL 또는 Build.PL에 사전 요구사항을 지정하세요
use로 Perl 버전 요구사항을 지정하세요
모듈에 테스트를 포함하세요
합리적이고 일관된 버전 번호 체계를 선택하세요 (X.YY가 일반적인 Perl 모듈 번호 체계)
아무리 작은 변경이라도 매번 버전 번호를 올리세요
"make dist"로 모듈을 패키징하세요
적절한 라이선스를 선택하세요 (GPL/Artistic이 좋은 기본값)

모듈 작성 시작 전에 (BEFORE YOU START WRITING A MODULE)

모듈 개발에 머리를 박고 돌진하지 말고, 먼저 생각할 시간을 조금 쓰세요. 약간의 선견지명이 나중에 엄청난 노력을 절약할 수 있어요.

이미 만들어졌나? (Has it been done before?)

어쩌면 모듈을 쓸 필요조차 없을 거예요. Perl에서 이미 이루어졌는지 확인하고, 좋은 이유가 없으면 바퀴를 다시 발명하지 마세요.

기존 모듈을 찾을 좋은 곳은 MetaCPAN과 [email protected]에서 물어보는 것이에요.

기존 모듈이 원하는 것을 거의 한다면, 다시 쓰는 것보다 패치를 쓰거나, 서브클래스를 쓰거나, 아니면 기존 모듈을 확장하는 것을 고려하세요.

한 가지 일을 하고 그것을 잘 하세요 (Do one thing and do it well)

자명한 말이 될 위험을 감수하지만, 모듈은 모듈형이도록 의도되었어요. Perl 개발자는 모듈을 사용해 애플리케이션의 빌딩 블록을 조립할 수 있어야 해요. 하지만 블록이 올바른 모양인 것이 중요하고, 개발자가 작은 블록만 필요할 때 큰 블록을 써야 하지 않아야 해요.

여러분의 모듈은 한 문장보다 길지 않은 명확하게 정의된 범위를 가져야 해요. 모듈을 관련 모듈의 가족으로 쪼갤 수 있나요?

나쁜 예:

"FooBar.pm provides an implementation of the FOO protocol and the related BAR standard."

좋은 예:

"Foo.pm provides an implementation of the FOO protocol. Bar.pm implements the related BAR protocol."

이것은 개발자가 BAR 표준용 모듈만 필요하다면, FOO용 라이브러리까지 설치하도록 강요받지 않아야 한다는 뜻이에요.

이름에 무엇이? (What's in a name?)

일찍 모듈에 적절한 이름을 선택해야 해요. 이것은 사람들이 모듈을 찾고 기억하는 데 도움이 되고, 모듈로 프로그래밍하는 것을 더 직관적으로 만들어요.

모듈 이름을 지을 때 다음을 고려하세요:

설명적이어야 해요 (즉 모듈의 목적을 정확히 설명).
기존 모듈과 일관되어야 해요.
구현이 아니라 기능을 반영해야 해요.
새 최상위 계층을 시작하지 마세요. 특히 모듈을 둘 수 있는 적절한 계층이 이미 존재한다면요.

공개하기 전에 피드백 받기 (Get feedback before publishing)

이전에 CPAN에 모듈을 업로드한 적이 없더라도(있더라도), 모듈의 애플리케이션 도메인과 CPAN 명명 시스템에 이미 익숙한 사람들에게 피드백을 받도록 강력히 권해요. 유사한 모듈이나 유사한 이름의 모듈 저자가 좋은 시작점일 수 있고, Perl Monks 같은 커뮤니티 사이트도 좋아요.

모듈 설계와 작성 (DESIGNING AND WRITING YOUR MODULE)

모듈 설계와 코딩에 대한 고려사항:

OO인가 아닌가? (To OO or not to OO?)

모듈은 객체지향(OO)일 수도 있고 아닐 수도 있고, 두 종류의 인터페이스를 모두 가질 수도 있어요. 각 기법에는 장단점이 있고, API를 설계할 때 이를 고려해야 해요.

Perl Best Practices(2004, O'Reilly Media 출판)에서 Damian Conway는 OO가 문제에 적합한지 결정할 때 사용할 기준 목록을 제공해요:

설계하는 시스템이 크거나, 커질 가능성이 있다.
데이터가 명확한 구조로 집계될 수 있고, 특히 각 집계체 안에 많은 양의 데이터가 있다.
다양한 데이터 집계 타입이 상속과 다형성의 사용을 촉진하는 자연스러운 계층을 형성한다.
많은 다른 연산이 적용되는 데이터 조각이 있다.
관련된 타입의 데이터에 동일한 일반 연산을 수행해야 하지만, 연산이 적용되는 특정 데이터 타입에 따라 약간의 변형이 있다.
나중에 새 데이터 타입을 추가해야 할 가능성이 있다.
데이터 조각 사이의 전형적인 상호작용이 연산자로 가장 잘 표현된다.
시스템의 개별 구성요소 구현이 시간에 따라 바뀔 가능성이 있다.
시스템 설계가 이미 객체지향적이다.
많은 수의 다른 프로그래머가 여러분의 코드 모듈을 사용할 것이다.

OO가 모듈에 적합한지 신중히 생각하세요. 불필요한 객체지향은 평균적인 모듈 사용자가 이해하거나 사용하기 어려운 복잡한 API를 만들 수 있어요.

API 설계 (Designing your API)

인터페이스는 평균적인 Perl 프로그래머가 이해할 수 있어야 해요. 다음 지침이 API가 충분히 간단한지 판단하는 데 도움이 될 수 있어요:

간단한 일을 하는 간단한 루틴을 작성하세요.

소수의 거대한 루틴보다 수많은 간단한 루틴이 더 좋아요. 루틴이 인자에 따라 동작이 크게 바뀐다면, 두 개(또는 그 이상)의 별도 루틴을 가져야 한다는 신호예요.

기능과 출력을 분리하세요.

결과를 가능한 가장 일반적인 형태로 반환하고, 사용자가 그 결과를 어떻게 사용할지 선택하게 하세요. 가능한 가장 일반적인 형태는 보통 텍스트 리포트, HTML, XML, 데이터베이스 쿼리, 또는 사용자가 요구하는 무엇이든 생성하는 데 사용할 수 있는 Perl 데이터 구조예요.

루틴이 어떤 종류의 목록(파일 목록, 데이터베이스 레코드 같은)을 반복한다면, 사용자가 목록의 각 요소를 차례로 조작할 수 있도록 콜백을 제공하는 것을 고려해 보세요. File::Find는 find(\&wanted, $dir) 문법으로 이 예를 제공해요.

합리적인 지름길과 기본값을 제공하세요.

간단한 결과를 얻기 위해 모든 모듈 사용자가 같은 고리를 뛰어넘게 요구하지 마세요. 더 복잡하거나 비표준 동작을 위해 항상 선택적 매개변수나 루틴을 포함할 수 있어요. 대부분의 사용자가 모듈을 사용하기 시작할 때 거의 동일한 코드 몇 줄을 입력해야 한다면, 그 동작을 기본값으로 만들었어야 한다는 신호예요. 대부분의 사용자가 같은 인자로 루틴을 호출한다면 그것도 기본값을 사용해야 한다는 좋은 지표예요.

명명 규칙 (Naming conventions)

이름은 일관되어야 해요. 예를 들어 이렇게 하는 것이 더 좋아요:

display_day();
display_week();
display_year();

이렇게 하는 것보다:

display_day();
week_display();
show_year();

이것은 메서드 이름, 매개변수 이름, 그리고 사용자에게 보이는 다른 모든 것(그리고 보이지 않는 대부분의 것!)에 동일하게 적용돼요.

매개변수 전달 (Parameter passing)

명명된 매개변수를 사용하세요. 이렇게 해시를 사용하는 것이 더 쉬워요:

    $obj->do_something(
	    name => "wibble",
	    type => "text",
	    size => 1024,
    );

... 이렇게 긴 이름 없는 매개변수 목록을 갖는 것보다:

$obj->do_something("wibble", "text", 1024);

인자 목록은 하나, 둘, 심지어 세 개까지는 잘 동작할 수 있지만, 그 이상이 되면 모듈 사용자가 기억하기 어렵고 모듈 저자가 관리하기 어려워져요. 새 매개변수를 추가하려면 하위 호환성을 위해 목록 끝에 추가해야 하고, 그러면 목록 순서가 직관적이지 않게 될 거예요. 또한 많은 요소가 undef일 수 있다면 다음과 같은 보기 싫은 메서드 호출을 볼 수 있어요:

$obj->do_something(undef, undef, undef, undef, undef, 1024);

기본값이 있는 매개변수에는 합리적인 기본값을 제공하세요. 거의 항상 같을 매개변수를 사용자가 지정하도록 만들지 마세요.

인자를 해시로 전달할지 해시레프로 전달할지 여부는 대체로 개인 스타일의 문제예요.

하이픈으로 시작하는 해시 키(-name)나 전부 대문자(NAME) 사용은, 보통 소문자 문자열이 => 연산자로 올바르게 처리되지 않던 옛 Perl 버전의 유물이에요. 일부 모듈은 역사적 이유나 개인 스타일로 대문자나 하이픈 인자 키를 유지하지만, 대부분의 새 모듈은 간단한 소문자 키를 사용해야 해요. 무엇을 선택하든 일관되게 하세요!

strict와 warnings (Strictness and warnings)

모듈은 strict 프래그먼 아래에서 성공적으로 실행되고 경고 없이 실행되어야 해요. 모듈은 적절한 곳에서 taint-checking도 처리해야 하지만, 많은 경우 어려움을 일으킬 수 있어요.

하위 호환성 (Backwards compatibility)

"안정적인" 모듈은 최소한 긴 전환 기간과 버전 번호의 큰 변경 없이는 하위 호환성을 깨뜨리지 않아야 해요.

에러 처리와 메시지 (Error handling and messages)

모듈이 에러를 만나면 다음 중 하나 이상을 해야 해요:

undef 값을 반환.
$Module::errstr 또는 유사한 것을 설정. (errstr은 DBI와 다른 인기 모듈이 사용하는 흔한 이름. 다른 것을 선택한다면 명확히 문서화하세요.)
STDERR로 메시지를 warn() 또는 carp().
모듈이 절대 뭘 해야 할지 알 수 없을 때만 croak(). (croak()는 호출자의 관점에서 에러를 보고하는, 모듈 안에서 사용하기 위한 더 나은 die() 버전이에요. croak(), carp() 및 다른 유용한 루틴의 세부사항은 Carp 참조.)
위의 대안으로 Error 모듈을 사용해 예외를 던지는 것을 선호할 수도 있어요.

구성 가능한 에러 처리는 사용자에게 매우 유용할 수 있어요. 경고와 디버그 메시지의 수준 선택, 별도 파일로 메시지를 보내는 옵션, 에러 처리 루틴을 지정하는 방법, 또는 다른 기능을 제공하는 것을 고려하세요. 이 모든 옵션을 가장 흔한 용도로 기본 설정하도록 하세요.

모듈 문서화 (DOCUMENTING YOUR MODULE)

POD

모듈은 Perl 개발자를 대상으로 한 문서를 포함해야 해요. 일반 기술 문서에는 Perl의 "plain old documentation"(POD)을 사용해야 하지만, 추가 문서(백서, 튜토리얼 등)는 다른 형식으로 작성하고 싶을 수도 있어요. 다음 주제를 다뤄야 해요:

모듈의 흔한 사용법의 시놉시스
모듈의 목적, 범위, 대상 애플리케이션
매개변수와 반환 값을 포함한 공개적으로 접근 가능한 각 메서드나 서브루틴의 사용법
사용 예제
추가 정보의 출처
저자/관리자의 연락 이메일 주소

Perl 모듈 문서의 상세 수준은 일반적으로 덜 상세한 것에서 더 상세한 것으로 가요. SYNOPSIS 섹션은 최소한의 사용 예제(어쩌면 코드 한 줄; 특이한 사용 경우나 대부분의 사용자가 필요로 하지 않는 것은 건너뛰세요)를 포함해야 하고, DESCRIPTION은 모듈을 대체로 몇 문단으로 설명해야 하며, 모듈의 루틴이나 메서드의 더 많은 세부사항, 긴 코드 예제, 또는 다른 심층 자료는 이후 섹션에 주어야 해요.

이상적으로, 모듈에 약간 익숙한 사람이 "page down"을 누르지 않고 기억을 되살릴 수 있어야 해요. 독자가 문서를 계속 읽어 나갈수록 점진적으로 더 많은 지식을 받아야 해요.

Perl 모듈 문서의 권장 섹션 순서는:

NAME
SYNOPSIS
DESCRIPTION
사용 가능한 메서드와 루틴, 그리고 다른 관련 정보의 더 큰 상세를 제공하는 하나 이상의 섹션 또는 하위섹션.
BUGS/CAVEATS 등
AUTHOR
SEE ALSO
COPYRIGHT and LICENSE

문서를 문서화하는 코드 가까이에 두세요("인라인" 문서). 주어진 메서드의 POD를 그 메서드의 서브루틴 바로 위에 포함하세요. 이렇게 하면 문서를 최신 상태로 유지하기 쉬워지고, 각 코드 조각을 두 번(한 번은 POD, 한 번은 주석) 문서화해야 하는 것을 피할 수 있어요.

README, INSTALL, 릴리스 노트, 변경로그

모듈은 모듈을 설명하고 추가 정보(웹사이트, 저자 이메일)에 대한 포인터를 주는 README 파일도 포함해야 해요.

INSTALL 파일을 포함해야 하고, 간단한 설치 지침을 담아야 해요. ExtUtils::MakeMaker를 사용할 때 보통:

perl Makefile.PL

make

make test

make install

Module::Build를 사용할 때는 보통:

perl Build.PL

perl Build

perl Build test

perl Build install

각 릴리스에 대해 소프트웨어의 사용자에게 보이는 변경을 사용자에게 관련된 용어로 설명하는 릴리스 노트나 변경로그를 만들어야 해요.

다른 형식을 쓸 좋은 이유(예: 회사 내에서 사용하는 형식)가 없다면, 변경로그 파일 이름을 Changes로 하고 CPAN::Changes::Spec에 설명된 간단한 형식을 따르는 것이 관례예요.

릴리스 고려사항 (RELEASE CONSIDERATIONS)

버전 번호 (Version numbering)

버전 번호는 최소한 메이저와 마이너 릴리스를 나타내고, 어쩌면 서브-마이너 릴리스도 나타내야 해요. 메이저 릴리스는 대부분의 기능이 바뀌거나, 주요 새 기능이 추가된 릴리스예요. 마이너 릴리스는 소량의 기능이 추가되거나 변경된 릴리스예요. 서브-마이너 버전 번호는 보통 문서 패치처럼 기능에 영향을 주지 않는 변경에 사용돼요.

가장 흔한 CPAN 버전 번호 체계는 이렇게 생겼어요:

1.00, 1.10, 1.11, 1.20, 1.30, 1.31, 1.32

올바른 CPAN 버전 번호는 소수점 뒤에 최소 2자리가 있는 부동소수점 숫자예요. 다음으로 CPAN에 부합하는지 테스트할 수 있어요:

perl -MExtUtils::MakeMaker -le 'print MM->parse_version(shift)' \
                                                        'Foo.pm'

모듈의 '베타'나 '알파' 버전을 릴리스하고 싶지만 CPAN.pm이 그것을 가장 최근으로 나열하기를 원하지 않는다면, 정규 버전 번호 뒤에 _ 그리고 최소 2자리를 사용하세요, 예: 1.20_01. 이렇게 한다면 다음 관용구를 권장해요:

our $VERSION = "1.12_01"; # so CPAN distribution will have
                          # right filename
our $XS_VERSION = $VERSION; # only needed if you have XS code
$VERSION = eval $VERSION; # so "use Module 0.002" won't warn on
                          # underscore

이 트릭으로 MakeMaker는 첫 줄만 읽어 밑줄을 읽고, perl 인터프리터는 $VERSION을 평가해 문자열을 숫자로 변환해요. 나중에 $VERSION을 숫자로 취급하는 연산은 $VERSION이 숫자가 아니라는 경고를 유발하지 않고 그렇게 할 수 있어요.

아무것도(한 단어 문서 패치조차) 버전 번호를 올리지 않고 릴리스하지 마세요. 한 단어 문서 패치조차 서브-마이너 수준에서 버전 변경이 되어야 해요.

한번 고르면, 자릿수를 줄이지 않고 버전 체계를 지키는 것이 중요해요. FreeBSD ports 시스템 같은 "다운스트림" 패키저가 버전 번호를 다양한 방식으로 해석하기 때문이에요. 버전 체계의 자릿수를 바꾸면 이런 시스템을 혼란스럽게 해 모듈 버전을 순서대로 못 얻을 수 있는데, 분명히 나쁜 일이에요.

사전 요구사항 (Pre-requisites)

모듈 저자는 다른 모듈에 의존할지, 어떤 모듈에 의존할지 신중히 고려해야 해요.

가장 중요하게, 가능한 한 안정적인 모듈을 선택하세요. 선호 순서로:

코어 Perl 모듈
안정적인 CPAN 모듈
불안정한 CPAN 모듈
CPAN에서 이용할 수 없는 모듈

Makefile.PL 또는 Build.PL의 사전 요구사항에 다른 Perl 모듈에 대한 버전 요구사항을 지정하세요.

Perl 버전 요구사항을 Makefile.PL 또는 Build.PL과 require 5.6.1 또는 같은 것으로 모두 지정하세요. 자세한 내용은 perlfunc의 use VERSION 문서를 보세요.

테스트 (Testing)

모든 모듈은 배포 전에 테스트해야 하고("make disttest" 사용), 설치하는 사람들도 테스트를 사용할 수 있어야 해요("make test" 사용). Module::Build에서는 make test에 해당하는 perl Build test를 사용해요.

이 테스트의 중요성은 모듈의 주장하는 안정성에 비례해요. 안정적이라고 주장하거나 널리 사용되기를 바라는 모듈은 가능한 한 엄격한 테스트 체제를 따라야 해요.

테스트를 쓰는 데 도움이 되는 유용한 모듈(개발 프로세스나 시간에 최소한의 영향을 미치면서)은 Test::Simple, Carp::Assert, Test::Inline을 포함해요. 더 정교한 테스트 스위트에는 Test::More와 Test::MockObject가 있어요.

패키징 (Packaging)

모듈은 표준 패키징 도구 중 하나를 사용해 패키징해야 해요. 현재 ExtUtils::MakeMaker와 더 플랫폼 독립적인 Module::Build 사이에서 선택할 수 있어, 모듈을 일관된 방식으로 설치할 수 있게 해주죠. ExtUtils::MakeMaker를 사용할 때 "make dist"로 패키지를 만들 수 있어요. MakeMaker 친화적인 스타일로 모듈을 빌드하는 데 도움이 되는 도구가 있어요. ExtUtils::ModuleMaker와 h2xs가 포함되죠. perlnewmod도 보세요.

라이선스 (Licensing)

모듈에 라이선스가 있고, 그 전문이 배포판에 포함되어 있는지 확인하세요(흔한 것이고 라이선스 조건이 포함을 요구하지 않는 경우 제외).

어떤 라이선스를 쓸지 모르겠다면, GPL과 Artistic 라이선스의 이중 라이선스(Perl 자체와 같음)가 좋은 생각이에요. perlgpl과 perlartistic을 보세요.

흔한 함정 (COMMON PITFALLS)

바퀴 다시 발명하기 (Reinventing the wheel)

CPAN이 이미 아주 잘 서비스하는 특정 애플리케이션 영역이 있어요. 한 예는 템플릿 시스템이고, 또 하나는 날짜·시간 모듈이며, 더 많이 있어요. 이런 것들의 자신만의 버전을 쓰는 것이 통과 의례지만, Perl 세계가 정말 그것을 공개할 필요가 있는지 신중히 고려하세요.

너무 많이 하려 함 (Trying to do too much)

여러분의 모듈은 개발자의 툴킷의 일부가 될 거예요. 모듈 자체가 전체 툴킷을 형성하지는 않아요. 코드가 모듈형 빌딩 블록의 집합이 아닌 단일체 시스템이 될 때까지 추가 기능을 더하는 것이 유혹적이에요.

부적절한 문서 (Inappropriate documentation)

잘못된 독자를 위한 글을 쓰는 함정에 빠지지 마세요. 주요 독자는, 모듈의 애플리케이션 도메인에 대해 어느 정도 이해하고 있는, 합리적으로 경험 많은 개발자이며, 방금 모듈을 내려받아 가능한 한 빨리 사용하기 시작하고 싶어 하는 사람이에요.

튜토리얼, 최종 사용자 문서, 연구 논문, FAQ 등은 모듈의 주요 문서에는 적절하지 않아요. 정말 이런 것을 쓰고 싶다면 My::Module::Tutorial이나 My::Module::FAQ 같은 하위 문서로 포함하고, 주요 문서의 SEE ALSO 섹션에 링크를 제공하세요.

더 알아보기 (SEE ALSO)

perlstyle — 일반 Perl 스타일 가이드
perlnewmod — 새 모듈 만드는 방법
perlpod — POD 문서
podchecker — POD 정확성 검증
ExtUtils::MakeMaker, Module::Build — 패키징 도구
Test::Simple, Test::Inline, Carp::Assert, Test::More, Test::MockObject — 테스트 도구
https://pause.perl.org/ — Perl Authors Upload Server
소프트웨어 공학에 관한 좋은 책 아무거나

저자 (AUTHOR)

Kirrily "Skud" Robert [email protected]

더 알아보기 (Learn more)

perlstyle — Perl 스타일 가이드
perlnewmod — 새 모듈 만들기
perlmod — Perl 모듈과 패키지
perlmodlib — 설치된 표준 모듈 목록
perlpod — POD 문서 형식