책너두 5기 41일차
로버트 C. 마틴의 클린코드 p. 379~ p.387
내용정리
17. 냄새와 휴리스틱
일반
15. 선택자 인수
선택자(selector) 인수는 목적을 기억하기 어려울 뿐 아니라 각 선택자 인수가 여러 함수를 하나로 조합한다. 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 일반적으로 좋다.
16. 모호한 의도
코드를 짤 때는 의도를 최대한 분명히 밝힌다.
17. 잘못 지운 책임
코드는 독자가 자연스럽게 기대할 위치에 배치한다.
18. 부적절한 static 함수
일반적으로 static 함수보다 인스턴스 함수가 더 좋다. 조금이라도 의심스럽다면 인스턴스 함수로 정의한다. 반드시 static 함수로 정의해야 겠다면 재정의할 가능성은 없는지 꼼꼼히 따져본다.
19. 서술적 변수
프로그램 가독성을 높이는 가장 효과적인 방법 중 하나가 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 방법이다.
20. 이름과 기능이 일치하는 함수
명명법은 잘하자
21. 알고리즘을 이해하라
알고리즘이 올바르다는 사실을 확인하고 이해하려면 기능이 뻔히 보일 정도로 함수를 깔끔하고 명확하게 재구성하는 방법이 최고다. 구현이 끝났다고 하기 전에 돌아가는 방식을 확실히 이해하는지 확인하라. 테스트 케이스가 모두 통과하는 것만으로는 부족하다. 돌아가는 것을 아는 것과 알고리즘이 올바르다는 사실을 아는 것은 다르다.
22. 논리적 의존성은 물리적으로 드러내라.
한 모듈이 다른 모듈에 의존한다면 물리적인 의존성도 있어야 한다. 의존하는 모든 정보를 명시적으로 요청하는 편이 좋다.
23. If/Else 혹은 Switch/Case 문보다 다형성을 사용하라.
새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch 문이 더 적합하다.
- 대다수 개발자가 switch 문을 사용하는 것은 올바르기보단 당장 손쉬운 선택이기 때문이다. 따라서 먼저 다형성을 고려해야 한다.
- 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물어서 모든 switch 문을 의심해야 한다.
선택 유형 하나에는 switch 문 한 번만 사용하는 ‘switch 문 하나’ 규칙을 따라라.
24. 표준 표기법을 따르라
업계 표준에 기반한 구현 표준을 따라야 한다. 팀이 정한 표준은 팀원들 모두가 따라야 한다.
25. 매직 숫자는 명명된 상수로 교체하라
일반적으로 코드에서 숫자를 사용하지 말라는 규칙이다.
읽고 나서
하지말란건 하지말자!
