지난 강에서 배운 Goto문은 언뜻 보면 괜찮아보입니다. 자유롭게 소스코드 어디론가 이동할 수 있다는 것 하나만으로도 충분히 여러 쓰임을 만들 수 있을 것 같습니다.

이번 강에서는 Goto를 사용하지 않아야 하는 이유를 자세히 설명드리도록 하겠습니다.

우선, Goto의 특징은 "어디든지 이동할 수 있는 자유로움"입니다. 이것이 프로그래밍에선 독이 됩니다.

여러분은 앞으로 고작 몇십줄이 아닌, 몇백 몇천줄의 코드를 작성하는 일이 허다할것입니다. 그러한 상황에서 오류가 나면 "디버깅"작업이라는 것을 해야합니다. 실제 코드가 어떻게 흐르고 있는지, 어느 부분을 어떻게 따라가다 오류가 나오는지 추적하는 일입니다. 즉, "오류 수정"작업입니다.

그러나 Goto문은 디버깅을 힘들게 하는 주범입니다. 어디 있을지도 모르는 레이블을 찾아 소스코드를 스크롤 하고 있는 것은 물론이고, Ctrl+F(찾기) 기능을 이용하는 행위 또한 생산성이 떨어지는 동작입니다.

위의 말을 요약하면 스파게티 코드가 되기 쉽다는 것입니다. 스파게티 코드는 컴퓨터의 흐름이 뒤죽박죽으로 엉킨 모습을 나타냅니다. 비록 잘 작동하는 것처럼 보이나, 코드를 보고 기능 추가 / 버그 수정등을 할 때 생산성이 엉망이 됩니다.

또한, Goto를 사용하면 현업에서 도태되기 마련입니다. Goto를 남용하여 코드 추적을 어렵게 만든다면, 같이 개발하는 팀원들에게 "같이 일 못하겠다"라는 말까지도 들을 수 있습니다. 물론 이유는 방금 말씀드린 이유 때문입니다. 그리고 여담이지만 오토핫키에서 Gosub은 return이 제대로 이루어지지 않았을 때 성능 하락 현상이 일어납니다.

Goto는 어셈블리어의 산물입니다. 과거의 유산이라는 뜻입니다. 실제로 요즘 나오고 있는 프로그래밍 언어들 중엔 Goto를 지원하지 않는 경우가 많습니다. 어차피 다른 구문으로 대체할 수 있기 때문입니다.

오토핫키 또한 Goto없이 모든 구문을 만들 수 있습니다. 그러니까 아래와 같은 끔찍한 코드를 작성하지 말고, 두 번째 예시처럼 Loop와 Break를 사용하여 반복문을 구성해야합니다.

아래 두 예시는 "이미지를 찾을 때까지 이미지 서치를 한 후, 찾으면 서치를 멈추고 대화 상자를 출력해라" 를 작성한 코드입니다.

Point1:
ImageSearch, vx, vy, 0, 0, 1920, 1080, *30 1.png
if (ErrorLevel = 0)
    goto, point2
goto, point1
point2:
MsgBox, 찾았습니다!
return

Loop
{
    ImageSearch, vx, vy, 0, 0, 1920, 1080, *30 1.png
    if (ErrorLevel = 0)
        Break
}
MsgBox, 찾았습니다!
return

타 언어에서 Goto를 써야하는 예외적인 상황이 있습니다. 다중 반복문 탈출 같은 경우에 Goto를 쓰는 경우가 많고, 예외처리를 즉시 할 경우 등이 있습니다.

오토핫키에선 Break 명령어의 매개변수로 빠져나갈 반복문의 수가 있고, 고급 예외처리인 try~catch문도 지원합니다.(배우지는 않았습니다.) - 예외처리 후 리소스 해제를 하는 구조의 경우, goto를 쓰는게 낫다라는 입장도 있습니다.

즉, 오토핫키에선 모든 Goto와 Gosub문을 다른 구문으로 대체할 수 있습니다. 절대 goto없이 못 짜는 구문이 보이시면 그건 그냥 본인의 실력 부족입니다.

이렇게까지 말씀 드렸는데 Goto와 Gosub을 쓰시겠다면 말리지 않겠지만, Goto를 적재적소에 잘 쓰는 사람은 아마 당신이 아닐거라는 말씀 드리고 싶습니다. 대부분의 사람이 Goto를 잘 쓰지 못합니다.

< 42. Goto와 Gosub | 43. 겉 모습에 속지 말라 | 44. 함수 >