Random bits of Perl advice

용어 배우기

To understand documentation, you need to know the jargon that it uses. Thisjargon is different from other programming languages, so don't think your Javaor C knowledge is any help.

문서를 이해하기 위해서는, 문서의 용어들을 알아야 합니다. 이 용어들은 다른 프로그래밍 언어들과는 다릅니다. 따라서 여러분의 Java나 C 지식이 도움이 될 것이라 생각해선 안됩니다.

Learning the jargon is part of the normal learning process. I recommend Beginning Perl, a free online book written by Simon Cozens.

용어를 배우는 것은 일반적으로 배우는 과정 안에 포함됩니다. 필자는 Simon Cozens가 저서한 무료 온라인 서적인「펄 제대로 배우기」를 추천합니다.

Here is an incomplete list of things that you will need to understand:

여기 여러분이 알고 이해해야 하는 일부 목록이 있습니다:

• 객체는 bless된 컨테이너의 레퍼런스이다. (An object is a reference to a blessed container.)
  
• 리스트는 배열과 같지 않다. (A list is not the same as an array.)
• 3개의 문맥이 존재한다: 보이드 문맥(컨택스트), 스칼라 문맥, 리스트 문맥. (There are three main contexts: void context, scalar context and list context.)
• 모든 것은 이름이 지어졌거나 익명(이름이없음)이다. (Things are named or anonymous.)
• Perl은 언어다. perl은 구현이다. 절대로 PERL이라고 쓰지 않는다. (The language is Perl, the implementation is perl. Never write PERL.)
• 연산자에는 문자열과 숫자 버전이 따로 있다. (There are different operators for strings and numbers.)
• 일부 연산자는 단락 논리 연산 을 수행한다. 이들에는 각각 낮거나 높은 우선순위 버전이 있다. (Some operators perform short circuit logical operations, and these have high and low precedence versions.)
• 지역 변수, 패키지 전역 변수, 그리고 main 네임스페이스에 반드시 포함되는 몇몇 패키지 전역 변수들이 있다. (There are lexical variables, package global variables and package global variables that are always in the main namespace.)
• 파라미터는 받아 들여지는 것이고. 아규먼트를 전달되는 것이다. (Parameters are expected, arguments are passed.)
• 연산자는 단항, 이항 또는 3항 연산자, 리스트 연산자 중 하나다. (An operator is either a unary, binary or ternary operator, or a list operator.)
• 하나의 statement(문장)는 하나 또는 여럿의 expression(표현식)으로 이루어진다. (A statement consists of one or more expressions.)
• 가독성을 높이기 위해 대안의 delimiter(구분문자)를 사용할 수 있다. (You can use alternative delimiters to avoid the leaning toothpick syndrome.)

If there is anything in this list you didn't know already or don't understand,go and find the documentation that explains it.

이 목록에 아직 모르거나, 이해하지 못하는 것이 있으면, 이를 설명하는 문서를 찾아봅니다.

코드의 일관성을 유지합니다

Programming style is a matter of personal preference, but there is one thingthat every style should have: consistency. I have described mystyle, and it's a good idea to describe your own style. That way you make sureyou cover important stuff, and it's a handy document to give people who areprogramming for you.

프로그래밍 스타일은 개인의 취향 문제입니다. 하지만 누구나 지켜야 하는 것이 있다면 바로 일관성입니다. 여기 필자의 스타일을 서술해 두었습니다. 그리고 여러분의 스타일을 만드는 것도 좋은 생각입니다. 그럼으로써 여러분은 여러분이 중요한 부분들을 놓치지 않았다고 확신할 수 있습니다. 그리고 다른 사람들이 여러분에게 코드를 작성해 줄 때에 제공할 수 있는 간편한 문서가 됩니다.

의미를 가지도록 서술합니다

Write what you mean, not just something that happens to work. This means youshould use scalar @array to get the number of elements in @array, andnot $#array + 1, because that would mean the index of the last elementof @array plus one

원하는 동작을 하는 코드가 아니라, 실제로 의미하는 바를 적습니다. 즉, @array의 원소 개수를 구하기 위해 scalar(@array)를 하는 것입니다. $#array+1 는 같은 값을 주지만, @array의 가장 마지막 인댁스에 1을 더한 값이라는 의미입니다.

깊은 들여쓰기는 피합니다

Code blocks and other things should be indented properly, of course, but whenyou have a maze of nested code blocks, think about writing it differently. Perlhas some nice controlled forms of goto that actually make code easier toread. They are redo, last and next. Also, avoid having hugeblocks indented. Any given code block larger than 24 lines is hard to read.

코드 블락이나 기타 것들은 제대로 들여쓰기되어야 합니다. 하지만 복잡하게 들여쓰기된 코드블럭이 있다면, 물론 다르게 작성하도록 생각해 봅니다. Perl 코드를 읽기 쉽게하는 goto의 변형된 버전이 있습니다. 이들은 redo, last, next 입니다. 또한, 많은 큰 블럭이 들여쓰기 되는 것은 피합니다. 24 줄이 넘는 어떠한 코드 블락도 읽기 힘듭니다.

For example, this:

예를 들어, 이것은:

for (...) {
    unless (foo) {
       # lots of code here
    }
    else {
        # some code here
    }
}

can be written as:

이와 같이 쓸 수 있습니다:

for (...) {
    if (foo) {
        # some code here
        next;
    }
    # lots of code here
}

이렇게 하면, 또 다른 작업이 수행되지 않을 것이란 것이 즉각 명백합니다. 이것은 여러분이,

if (open ...) {
    # entire
    # program
    # here
}
else {
    print STDERR $!;
}
__END__

Consider using or next and or last.

or next 나 or last 를 사용하도록 합니다.

정리할 필요 없도록 합니다

If you get your data clean, you don't have to clean it up. For example, you canread in a file and then remove lines that contain only whitespace, but it's betterto just make sure there are no such lines in the first place:

여러분의 데이터가 깨끗하다면, 정리할 필요가 없습니다. 예를 들어, 여러분은 파일을 열어서 공백문자만 포함하는 줄들을 제거할 수 있습니다. 하지만 그전에 그런 줄이 하나도 없는지 확인하는게 좋겠습니다.

my $file; /\S/ and $file .= $_ while readline $fh;

Most of the time, when you have an s/// with nothing in the RHS (righthand side), that means you're cleaning up because of mistakes you made before.(Or it is user input, and you really wanted to capture what you want instead ofremove what you don't want.)

대부분의 경우에는, s/// 연산자의 우측 항에 아무것도 없는 형태는 실수를 했기 때문에 지워내는 경우입니다. (그게 아니라 사용자 입력이었다면, 원하지 않는 부분을 제거 함으로써 원하는 부분만 가져오기 위해서)

Perl이 여러분을 돕도록 합니다

When you use strict, Perl forces you to declare variables before you canuse them. This means sticking my in front of a variable the first timeyou use it. That way, Perl knows when you make a typo. This can save you manyhours of debugging.

use strict 를 통해 strict 프래그마를 사용하면, Perl은 여러분이 변수를 사용하기 전에 반드시 선언하도록 강제합니다. 이렇게하여 가장 처음 사용할때 반드시 my 를 붙이도록 합니다. 이렇게 하면 여러분이 오타를 내었을 때 Perl이 발견해줄 수 있습니다. 이로 많은 시간의 디버깅시간을 단축해 줍니다.

When you use warnings or the -w command line argument, Perl gives additional warnings. This can be unwanted in rare situations, but you can justuse no warnings there to temporarily disable them.

use warnings 를 통해, 또는 명령줄 인자로 -w 를 넘겨서, warnings 프래그마를 사용하면, Perl은 부가적인 경고를 발생하여 줍니다. 몇몇 상황에서는 원하지 않을 수 있습니다. 하지만 이 경우에는 잠시 이를 끄기 위해 no warnings 를 쓰기만 하면 됩니다.

When hiring a programmer or buying code, never accept code that doesn't usestrict, unless they have a very good reason. That reason should be explainedat the place where use strict normally is: the top of the file.

개발자를 구하거나 코드를 사들일때, use strict 가 없는 코드는 대단히 합리적인 이유가 있지 않는 한 절대로 수용해서는 안됩니다.

도움을 얻을 수 있는 경로를 알아둡니다

First stop is documentation. Never ask for help before trying to figure it outon your own. If you ask for help and you get a reference to documentation asthe answer, don't whine, but read that documentation.

가장 먼저 살펴보아야 하는 것은 문서입니다. 절대로 여러분 스스로 생각해보기도 전에 먼저 다른사람에게 질문하지 않습니다. 여러분이 도움을 청했을 때 답에 대한 문서 링크를 받았을 때에는, 징징대지 않습니다. 다만 문서를 읽으십시오.

People have already written answers to your questions. This was done to avoidhaving to answer the same questions over and over.

사람들은 이미 여러분의 질문에 대한 답을 적어두었습니다. 계속 같은 질문이 중복하는 것을 피하기 위해서입니다.

The official Perl documentation is available using the perldoc tool. Tostart reading, type perldoc perl. This will guide you to other documents,like perldoc perlvar, which explains all the special variables.

perldoc 이라는 공식 Perl 문서가 있습니다. 처음 소개를 보기 위해 perldoc perl 이라고 입력합니다. 모든 특수 변수들을 설명하는 perldoc perlvar와 같은 다른 문서들의 목차를 제공해 줍니다.

You can get Perl help at PerlMonks, #perlhelp on EFnet, several usenet groupsand many more places.

PerlMonks 에서 Perl 관련 도움을 얻을 수 있습니다. 또는 EFnet의 #perlhelp 채널, 그리고 여러 usenet 등이 있습니다. 추가로 HanIRC의 #perl 채널과, Freenode의 #perl-kr 채널에서 한글로 질문하실 수 있습니다.

Oh, and remember that receiving help is a privilege, not a right. It's okayto ask for help, it's not okay to demand help.

아, 그리고 도움을 얻는 것은 권한이 아님을 명심하십시오. 도움을 요청하는 것은 좋은 일입니다. 하지만 도움을 요구하지는 마십시오.