소스코드리뷰(III) 다중 중첩을 제거하라

다중 if 문, 다중 case, for문등은 가급적 없애도록 한다

컴파일러는 중첩된 구문을 허용하고 최대 8중 구조등을 허용하지만 실제로 중첩구문을 쓰는 경우는 많아야 3중 구조 정도다.

(아무리 찔려도 이 선인장만큼은 찔리지 않는다.)

소스코드 리뷰하면 찔리는 부분이 많은데, 계속해서 리뷰를 해보자.

대학생때에 친구와 수수께끼 문제를 프로그램으로 계산하느라 중첩반복문을 써본 적은 있는데 그때 알게된 PC용 FORTRAN의 최대 중첩은 8중구조였다. 다행히 친구와 나는 6중구조로 프로그램을 실행하였다. 그 이후 지금까지 중첩문을 써왔지만 4중구조를 넘기는 일은 없었다.

중첩이 많아서 들여쓰기가 발생하는 경우는 먼저 논리적 결함이 있다고 보아도 좋다. 그리고 함수설계가 설계적 결함이 있다고 보아도 좋다. 비록 원하는 계산을 오류없이 수행할 수 있다고 하여도 좋은 소스코드는 되지 못한다.

그럼, 중첩을 피하는 방법은 있는가?

작은 서브루틴(함수, 프로시저)을 사용하여 구문을 분해하여야 한다. 다음에 다시 논의할 기회가 있겠지만 작은 서브루틴이 자유도가 높은 프로그램을 구성하는 컴포넨트 지향 설계가 가능하다. 이것은 마치 쌀알갱이로는 원하는 형상을 만들기 어렵지만 쌀을 빻아서 쌀가루를 만들면 쉽게 성형하는 것과 비슷하다.

객체지향 프로그래밍입문(An Introduction to Object-Oriented Programming)의 저자 버드도 이런 점을 지적하고 있다. 함수가 작으면 함수 호출의 오버헤드가 증가하지만, 현대의 고성능 프로세서에서는 오버헤드가 문제되는 것은 수나노초에 불과하다하므로 함수의 유용성에 초점을 맞추는 것이 유리하다.