항목 20 : 너무 긴 함수와 많은 중첩구조는 피하라. ( Avoid long functions. Avoid deep nesting. )

{

왜 그럴까? 역시 가독성을 무척 떨어 뜨리기 때문이다. 여기서 한가지 생각해 볼만한게 있는데, 수많은 책들이 성능보단 가독성이 나쁘면 왜 좋지 못한 코드라고 할까? 내가 경험한 바, 성능을 아무리 좋게 한다고, 성능 위주 코드를 짠다 해도, 차이가 없기 때문이다. 이 이야기는 다음의 이야기를 증명해 주기도 한다.

"성능의 향상은 코드에 있는것이 아니고, 프로그램의 "알고리즘"에 있다"

그렇기 때문에, 우선 코드를 잘 보이도록 짠 뒤에, 알고리즘을 개선 하는 방향으로 가는것이 진정한 성능 향상이라 할 수 있다. 그래서 가독성을 해치는 "너무 긴 함수와 많은 중첩구조는 피하라" 라고 하는 것이다.

코드를 가독하는 사람의 입장에서 함수가 너무 길면, 그 내용을 모두 기억한 채로 위에서 아래로 코드를 훓어야 한다. 이런 것이 전체 코드에서 한두개라면, "뭐~ 그러려니 하지~" 라고 넘기지만, 계속 쌓이다 보면, 사람으로썬 도저히 기억해 가며 훓을 수 없게 되는 것이다. 결국 "가독성 하락" 과 이어진다.

중첩구조 역시 마찬가지로 중첩된 상태를 머리속으로 다시 그려넣어야 하는 사람 입장에선 무척이나 읽기 까다롭다.

그래서~ "너무 긴 함수와 많은 중첩구조는 피하라" 라고 이야기 하는 것이다.

책에 나온 요령으로는
1. 하나의 함수가 하나의 역활만 갖게 한다.
2. 반복되는 비슷한 코드는 함수로 만들어서 재사용 하라.
3. if 구조에서 && 를 사용하라. 중첩된 if는 보기만 해도 짜증난다. 개인적으로 && 까지 사용해서 두개가 적당하다. 더 많은 더 보기 어렵더라.
4. try를 복잡하게 사용하지 마라.
5. 루프보단 알고리즘을 사용 하라.
6. 타입 태그에 switch 구문을 사용하지 말라.

마지막 6번은 말은, 타입을 확인하여 특정 함수가 호출되게 분기하는 로직을 짜지 말고, 다형성(Polymorphism)을 이용한 분기가 더 보기 편하다는 이야기이다.(사람이 따라서 이게 더 나쁘게 보일 수도 있겠다.)

}