[월:] 2004년 12월

흔히들 GOTO 문의 사용은 가능하면 억제 하는 것이 좋다고 말을 한다. 그 이유는 논리적 흐름을 따라가는 문맥을 무시하고, 원하는 곳으로 이동할 수 있는 논리파괴의 절대적인 권리를 사용하기 때문이다. 그러한 속설에도 불구하고 여러가지 특정한 형태에서 GOTO문의 사용이 더 효과적임을 입증하는 코드들도 예시되고 발견되어서, 결과적으로는 프로그래머에의해 완벽히 제어되고 모듈화된 코드의 내부에서 사용하는 것은 효율적일 수도 있다고 여겨지는 것 같다.

RETURN 문의 사용도 이와 비슷한 맥락에서 이해할 수 있다. 어떤 함수의 내부 구현에 있어서 입구는 하나, 그러므로 출구도 하나. 인것이 가장 자연스럽다. (return 형이 void가 아니라면) 함수의 이름과 파라메터가 적힌 함수의 머리와 마지막줄에 return 문이 짝을 이룬 구조가 가장 논리적으로 무결성을 지닌다는 것이다.

함수의 실행 중간에 return 문을 여러게 쓴 함수의 구조는 일단 메모리 누수의 위험이 크다. 보통 함수의 앞부분에서 이루어지는 메모리의 할당, 객체의 생성이 return 문이 2개일때는 각각의 메모리 해제 코드와 짝지어 져야 한다. 즉 중복된 코드를 사용해야 하고, 이를 잊었을때는 메모리 누수의 위험에 노출된다.

또한 “return 상수” 형태의 코드도 지양해야 한다. 이런 코드는 다양한 값의 리턴을 위해서는 필수적으로 다수의 return 문이 포함 되어야 한다. 이는 위에서 언급한 문제의 원인이 된다.

함수를 작성하는 것도 글을 쓰는것과 같다. 함수의 제목 즉 글의 제목은 이 함수가 무엇을 말하고, 서술하는지 알기 쉽게 보여준다. 전반부에는 본문에서 사용할 각종 논제, 변수 들의 선언과 할당이 이루어 진다. 본문에서는 실제 이 논제들을 가지고 어떤 목표를 위한 논리를 이끌어 나간다. 결론부에서는 각종 논제들을 마무리 짓고 하나의 명확한 결론을 도출해 낸다.

결국 논리적으로 완성된 함수, 글은 하나의 RETURN, 결론 만을 가진다.