Perl-코딩 표준

물론 각 프로그래머는 형식 지정과 관련하여 자신의 선호도를 가지고 있지만 프로그램을보다 쉽게 읽고 이해하고 유지 관리 할 수 있도록 몇 가지 일반적인 지침이 있습니다.

가장 중요한 것은 항상 -w 플래그로 프로그램을 실행하는 것입니다. no warnings pragma 또는 필요한 경우 $ ^ W 변수를 통해 코드의 특정 부분에 대해 명시 적으로 해제 할 수 있습니다. 또한 항상 엄격하게 사용하거나 그 이유를 알아야합니다. sigtrap을 사용하고 진단 pragma를 사용하는 것도 유용 할 수 있습니다.

코드 레이아웃의 미학과 관련하여 Larry가 강하게 관심을 갖는 유일한 점은 다중 행 BLOCK의 닫는 중괄호가 구성을 시작하는 키워드와 일치해야한다는 것입니다. 그 외에도 그는 그다지 강하지 않은 다른 선호도를 가지고 있습니다.

4 열 들여 쓰기.
가능하면 키워드와 같은 줄에 곱슬을 열고 그렇지 않으면 줄을 섭니다.
여러 줄 BLOCK의 여는 곱슬 앞의 공백.
한 줄 BLOCK은 컬리를 포함하여 한 줄에 놓을 수 있습니다.
세미콜론 앞에 공백이 없습니다.
"짧은"단선 BLOCK에서 세미콜론이 생략되었습니다.
대부분의 운영자 주위에 공간.
"복잡한"아래 첨자 주위의 공백 (괄호 안에).
다른 일을하는 청크 사이의 빈 줄.
껴안고 다른 사람들.
함수 이름과 여는 괄호 사이에 공백이 없습니다.
각 쉼표 뒤의 공백.
연산자 뒤의 긴 줄 (및 및 또는 제외).
현재 줄에서 일치하는 마지막 괄호 뒤의 공백.
해당 항목을 세로로 정렬합니다.
명확성이 떨어지지 않는 한 중복 구두점을 생략하십시오.

생각해야 할 또 다른 실질적인 스타일 문제가 있습니다. 특정 방식으로 무언가를 할 수 있다고해서 그렇게해야한다는 의미는 아닙니다. Perl은 무엇이든 할 수있는 여러 가지 방법을 제공하도록 설계되었으므로 가장 읽기 쉬운 방법을 선택하는 것이 좋습니다. 예를 들어-

open(FOO,$foo) || die "Can't open $foo: $!";

보다 낫다-

die "Can't open $foo: $!" unless open(FOO,$foo);

두 번째 방법은 수정 자에서 명령문의 요점을 숨기기 때문입니다. 반면에

print "Starting analysis\n" if $verbose;

보다 낫다-

$verbose && print "Starting analysis\n";

요점은 사용자가 -v를 입력했는지 여부가 아니기 때문입니다.

Perl이 마지막 연산자를 제공하므로 중간에서 종료 할 수 있으므로 어리석은 왜곡을 통해 상단 또는 하단의 루프를 종료하지 마십시오. 좀 더 잘 보이게하려면 약간 "내어 쓰기"만하면됩니다.

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

몇 가지 중요한 사항을 더 살펴 보겠습니다.

루프 레이블을 사용하는 것을 두려워하지 마십시오. 가독성을 높이고 다중 레벨 루프 중단을 허용하기 위해 존재합니다. 이전 예를 참조하십시오.
grep () (또는 map ()) 또는`backticks`를 void 컨텍스트, 즉 반환 값을 버릴 때 사용하지 마십시오. 이러한 함수에는 모두 반환 값이 있으므로 사용하십시오. 그렇지 않으면 foreach () 루프 또는 system () 함수를 대신 사용하십시오.
이식성을 위해 모든 시스템에서 구현되지 않을 수있는 기능을 사용할 때 평가에서 구성을 테스트하여 실패하는지 확인하십시오. 특정 기능이 구현 된 버전 또는 패치 수준을 알고 있다면 $] (영문 $ PERL_VERSION)를 테스트하여 해당 기능이 있는지 확인할 수 있습니다. Config 모듈을 사용하면 Perl이 설치되었을 때 Configure 프로그램에서 결정한 값을 조사 할 수도 있습니다.
니모닉 식별자를 선택합니다. 니모닉이 무엇을 의미하는지 기억할 수 없다면 문제가있는 것입니다.
$ gotit과 같은 짧은 식별자는 괜찮지 만, 긴 식별자에서 단어를 구분하려면 밑줄을 사용하십시오. 일반적으로 $ VarNamesLikeThis보다 $ var_names_like_this를 읽는 것이 더 쉽습니다. 특히 영어가 모국어가 아닌 경우 더욱 그렇습니다. 또한 VAR_NAMES_LIKE_THIS와 일관되게 작동하는 간단한 규칙입니다.
패키지 이름은 때때로이 규칙의 예외입니다. Perl은 integer 및 strict와 같은 "pragma"모듈에 대해 소문자 모듈 이름을 비공식적으로 예약합니다. 다른 모듈은 대문자로 시작하고 대소 문자를 혼용해야하지만, 기본 파일 시스템의 모듈 이름 표현이 몇 개의 스파 스 바이트에 맞아야하는 파일로 제한되기 때문에 아마도 밑줄이 없을 것입니다.
정말 털이 많은 정규식이 있다면 / x 수정자를 사용하고 약간의 공백을 넣어 라인 노이즈처럼 보이게 만듭니다. 정규 표현식에 슬래시 또는 백 슬래시가있는 경우 슬래시를 구분 기호로 사용하지 마십시오.
항상 시스템 호출의 반환 코드를 확인하십시오. 좋은 오류 메시지는 STDERR로 이동하고, 어떤 프로그램이 문제를 일으켰는지, 실패한 시스템 호출과 인수가 무엇인지, (매우 중요) 무엇이 잘못되었는지에 대한 표준 시스템 오류 메시지를 포함해야합니다. 다음은 간단하지만 충분한 예입니다.

opendir(D, $dir) or die "can't opendir $dir: $!";

재사용 가능성에 대해 생각하십시오. 그런 일을 다시하고 싶을 때 왜 원샷에 두뇌 능력을 낭비합니까? 코드 일반화를 고려하십시오. 모듈 또는 객체 클래스 작성을 고려하십시오. 엄격하게 사용하고 경고 (또는 -w)를 적용하여 코드를 깨끗하게 실행하는 것을 고려하십시오. 코드를 제공하는 것을 고려하십시오. 전체 세계관을 바꾸는 것을 고려하십시오. 생각 해봐 ... 오, 신경 쓰지 마.
일관성을 유지하십시오.
착하게 굴 어라.