프로그래밍 스타일, 하나의 함수에 하나의 리턴!?

상황봐서 중복해서 써야 한다면 쓰지만 되도록 안 쓰자는 주의죠.
continue 는 if else 로 바꿔서 쓰기 때문에 거의 안 씁니다.

하지만 가독성이란 사람의 심리적인 면도 상당히 강하기 때문에 주관성이 강하죠.

몇십줄이라면 봐줄만 하겠지만 역시 긴 함수는 좀더 짧은 함수로 바꿔주는 것도 한 방법입니다.
가독성이 좋다면 한번만 호출되도 짧은 함수로 쪼개는 것을 생각해 볼만 합니다.
Test 에도 좋고요.

Code Complete 에서는 if else 의 조건식 순서에 정형화된 style 을 주어서 하기를 권장합니다.
이 style 에 맞춘다면 break, continue, return 이 쓰일 일이 많겠죠.

return 을 한번만 쓰자는 것이 반드시 옳다면 programming 언어 차원에서 아예 제한을 걸 수도 있을 겁니다.
그렇지 않다는 것은 이유가 있습니다.
하지만 이런 이야기가 나온 것도 나름의 이유가 있기에 고찰해보면 code 정리에 도움이 많이 됩니다.

비정상, 에러 상황이 발생하면 바로 리턴하고

그렇지 않으면 보통 마지막에 리턴합니다.

----------------------------------------------------------------------------
C Library Development Project

> 어느 책에서였던가...
> 하나의 함수에 하나의 리턴문만을 쓰는것이 좋은 프로그래밍 습관이라고 읽은적이 있는데요
> 꽤 오래전에 읽었는데 어디에서 읽었는지 모르겠네요
>

제 책에도 동일한 내용이 있는 것으로 기억합니다.

> 그런데 초보인 저로써는 이걸 지키기가 꽤나 힘듬니다
> 함수의 인자 몇개를 검사하고 처리결과 대신 오류를 리턴해야하는 일이 있을경우
> 하나의 리턴문을 만들기 위해 함수 전체를 몇개의 if-else로 감싸니
> 지독한 들여쓰기로 가독성이 상당히 떨어지게 되던데요
>
> 지금에서야 다시 생각해보면...
> 몇십라인이 되는 함수 곳곳에 리턴문이 있는것과(다른 코드들과 섞여서 리턴문이 잘 보이지 않게되는)
> 함수의 마지막 라인에 유일한 리턴문이 있는것과(함수전체에 걸치는 if-else로 인해 많은 들여쓰기가 된)
> 어느게 더 좋다고 할수있는지 잘 모르겠습니다
>

"one entry point and one exit point" 원칙은 말 그대로 코딩 스타일의
문제입니다. "들여쓰기는 몇 칸을 해라" 같은 스타일보단 강한 성격을
갖지만, "함수 하나의 길이는 몇줄로 제한해라"와 같은 스타일과는 크게
다르지 않다고 볼 수 있습니다.

"코딩 스타일"이란 손해나 불이익을 감수하고 논리적 모순에 빠지면서
까지 지켜야 하는 규칙이라기 보다는 그 스타일이 전달하고자 하는
"개념"을 지키겠다는 생각으로 접근하면 충분하다고 봅니다.

"one entry point and one exit point" 의 스타일이 말하고자 하는 바는
사용한 자원에 대한 뒷정리가 필요한 경우에는 이 스타일을 지킴으로써
혹은 지키려 노력함으로써 처음부터 memory leak 같은 자원 관리에
생기는 문제를 피해갈 수 있다는 것입니다 (실은 structured programming
에서 단일 repeatation 구문에 적용되는 원칙입니다만, 실용적인 관점에서
저 스타일을 통해 얻을 수 있는 바를 설명했습니다). 그와 같은 코딩
스타일이 "품는" 개념은 보지 않고 코딩 스타일이 "표면적으로 말하는"
것만을 지키려할 경우 오히려 모순되는 상황에 빠질 가능성이 큽니다.

예를 들어, 말씀하신 것과 같은 상황에서 "if 문 중첩의 깊이는 몇개 이상
으로 해서는 안 된다" 같은 스타일과 문제의 스타일이 상충된다면 어떻게
하시겠습니까? 혹은 위에서 언급한 것처럼 "함수의 길이를 몇 줄로 제한
해라" 라는 스타일과 "하나의 함수에는 하나의 완전한 논리적, 기능적
단위 만을 담아라" 라는 스타일이 상충된다면 어떻게 하시겠습니까?

스타일은 경우에 따라 "합리적으로" 무시할 수 있기에 스타일입니다. 예를
들어, 어떤 분은 "one entry point and one exit point" 원칙이 부적당
하다고 판단해 "two exit points" (하나는 함수가 성공한 경우, 다른 하나
는 실패한 경우) 를 나름의 기준으로 세워 코딩을 하기도 합니다.

긴 시간 동안 여러 개발자들을 통해 전해온 스타일은 대부분의 경우 그
가치를 가지고 있습니다. 만약, 지금 당장 그와 같은 스타일이 도움은
커녕 방해만 된다고 판단하신다면 무시하셔도 괜찮습니다. 어차피 긴 시간
개발을 진행하다보면 누가 지키지말라고 해도 방어적으로 그와 같은
스타일을 지켜 코딩하는 자신의 모습을 발견하실 수 있을 것입니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

한 함수의 return이 여러곳에서 수행되어서, 그 함수를 "사용"하는데 곤란한 점이 있나요? return하는 경우에 따라 뭐가 달라진다.. 이런 것은 함수의 내부를 들여다 보기 이전에 잘 정의해서 문서화를 해주고, "사용"만 해야지, 안을 들여다볼 필요는 없다고 생각하거든요.

문제가 되는 것은 그 함수를 들여다보고 수정해야 하는 경우 같은데..

그 함수를 수정하려고 하는데 return이 너무 많은 곳에서 이루어져서 곤란하다면, 그건 함수를 기능별로 더 쪼개야 한다는 뜻이 되지 않을까요? 또는 예외 처리를 활용해서,try-catch 부분에서만 return하게 만든다던가, 아니면 위 처럼 goto 문을 활용한다던가 해서 일관적으로 작성하면 무난할 것이라고 생각해봅니다~

예를 들어 특정 알고리즘을 구현할 경우, 알고리즘을 이해하면 중간에 이런식으로 리턴하는 걸 이해하겠죠. 코드의 내용 (알고리즘)을 알지 못하고 "리턴이 왜 여깄지? 의미가 뭐지?"라고 궁금해 하지 않도록 뒤로 잘 몰아준다고 해서 그 코드를 잘 수정할 수 있게 되는 건 아니죠.. 그 코드를 단지 이용하는 것이면 함수로 이용하면 되는 것이고요~