저도 실명.ID 식으로 변경했습니다....흐흐흐흐
여자이름으로 보이십니까? 아쉽게도 저도 남자입니다 ㅡㅡ; (옆구리 시려워요~)
-------------------------------------------------------------------

우리는 보통 실행시키면 그 결과로 배열이나 리스트 오브젝트(이하 리스트)를 뱉어내도록 하는 함수를 자주 만듭니다.
하지만 여기서 사람들이 큰 두 그룹과 작은 하나의 그룹으로 나뉘어지는데...

먼저 작은 하나의 그룹은 (하지만 여기에 대부분의 델파이 개발자가 포함된다는거) 아예 배열이나 리스트가 반환되지 않도록 코딩합니다.
배열이나 리스트를 인자로 넘겨서 내부에서 지지고 볶고 한 다음에 반환을 '바로 그', 또는 '추가로 생성해서 인자로 넘긴' 배열이나 리스트에다가 하지요.
이래서 function을 procedure(void)로, 혹은 배열이나 리스트의 길이를 리턴하는 function으로 만듭니다.


하지만 요즘 유행하는 나머지 큰 두 그룹의 경우 이런 함수를 만드는데 주저함이 없습니다.
(참고: 이런 식으로 함수가 조건에 따라 어떤 오브젝트를 뱉어내는 경우를 패턴에서는 팩토리 함수라고 하죠.)
그럼 여기서 두 개의 커다란 그룹이 무엇이냐? 하는 답이 나와야 인지상정!
(이라고 말할거라고 예상한 사람? 없나요?)

첫번째 그룹은 반환될 배열이나 리스트 오브젝트가 비어있을 때 null을 반환합니다.
두번째 그룹은 말 그대로 빈 배열이나 빈 리스트 오브젝트를 반환합니다.


- 첫번째 그룹 (null 반환) -

이 그룹의 장점은 아무래도 메모리 할당/해제 속도에 대한 이득을 얻는다는거겠죠.

단점은? 없다고 생각하십니까? 진짜로?
단점은 바로 프로그래머가 null이 넘어오는지 일일히 체크해야 한다는 겁니다.
그러면 당근 코딩량이 늘어나죠. 혹시나 버그가 날까 노심초사 해야 할 수도 있습니다.
(젠장! 차라리 제일 위의 방식이 낫겠어!)


- 두번째 그룹 (빈 배열/리스트 반환) -

이 친구들의 경우에는 바로 결과 가지고 루프돌면 됩니다.
한가지 멋진 사실은, null을 처리하기 위한 추가 코딩도 필요가 없다는 겁니다. 에러도 없지요. 버그요? 물론 없습니다.

단점은 첫번째 그룹의 장점의 반대죠. 메모리 할당/해제에 대한 오버헤드가 있습니다. 특히 자주 할당/해제가 난다면 치명적일 수도 있겠네요.
그리고 메모리 해제를 함수를 호출한 쪽에서 해야 한다는것, 잊지 마시구요.

하지만 이 경우에는 장점이 단점을 상쇄하고도 남는다고 생각합니다.


이 글에는 결론을 못내겠군요.
이 자체만으로도 논쟁거리가 될 소지가 충분하기 때문에
제가 여기다가 결론을 내버리면 아주 난리가 나겠지요.... 헤헤

개인적으로는 두번째 그룹처럼 씁니다.
요즘은 Java가지고 많이 놀다보니 특히 두번째 방식이 아주 좆쿠나 라는걸 많이 느끼죠.
(아차! 결론을 내버렸다!!! orz)

반론은 언제든지 환영합니다. 하지만 너무 과격하게는 적지 마세요!