클린 코드 독서일지 - Day 40

G15: 선택자 인수

선택자 인수 : 함수나 메서드의 인수 중 하나가 다른 인수들의 처리 방식을 결정하는 역할을 하는 것.

선택자 인수는 목적을 기억하기 어려울 뿐 아니라 각 선택자 인수가 여러 함수를 하나로 조합함
ex: calculateWeeklyPay(false) 같은 함수의 boolean 인수
일반적으로 인수를 넘겨 동작을 선택하는 대신 새로운 함수를 만드는 편이 좋다.

G16: 모호한 의도

코드를 짤 때는 의도를 최대한 분명히 밝힌다.

• 행을 바꾸지 않고 표현한 수식, 헝가리식 표기법, 매직 번호 등은 모두 가독성을 흐림 => 피하는 게 좋음

G17: 잘못 지운 책임

코드를 배치할 때는 독자가 자연스럽게 기대할 위치에 배치한다.
ex) PI 상수는 삼각함수를 선언한 클래스에 배치
기능을 개발에 편리한 곳에 배치하고자 할 땐, 함수 이름을 다르게 변경하여 독자로 하여금 예상할 수 있도록 한다.

G18: 부적절한 static 함수

함수를 재정의할 가능성이 있으면 static 함수로 정의하면 안 됨
-> 일반적으로 static 함수보다 인스턴스 함수가 더 좋으므로, 조금이라도 의심스럽다면 인스턴스 함수로 정의한다.

G19: 서술적 변수

프로그램 가독성을 높이는 가장 효과적인 방법 중 하나는 계산을 여러 단계로 나누고 중간 값으로 서술적인 변수 이름을 사용하는 것임
서술적인 변수 이름은 많을수록 좋으며, 가독성을 크게 증가시킨다.

G20: 이름과 기능이 일치하는 함수

이름만으로 분명하지 않기에 구현을 살피거나 문서를 뒤적여야 한다면 더 좋은 이름으로 바꾸거나 더 좋은 이름을 붙이기 쉽도록 기능을 정리해야 한다.

G21: 알고리즘을 이해하라

구현이 끝났다고 선언하기 전에 함수가 돌아가는 알고리즘을 정확히 이해하는지 확인하라

G22: 논리적 의존성은 물리적으로 드러내라

한 모듈이 다른 모듈에 의존한다면 물리적인 의존성도 있어야 한다.
=> 의존하는 모듈이 상대 모듈에 대해 뭔가를 가정하면(논리적으로만 의존하면) 안 됨

G23: If/Else 혹은 Switch/Case 문보다 다형성을 사용하라

switch를 선택하기 전에 다형성을 먼저 고려하라.

• 새 유형을 추가할 확률보다 새 함수를 추가할 확률이 높은 코드에서는 switch문이 더 적합하지만, 유형보다 함수가 더 쉽게 변하는 경우는 극히 드물기 때문에 모든 switch 문을 의심해야 한다.
  선택 유형 하나에는 switch 문을 한 번만 사용한다. -> 같은 선택을 수행하는 다른 코드에서는 다형성 객체를 생성해 switch문을 대신

G24: 표준 표기법을 따르라

팀은 업계 표준에 기반한 구현 표준을 따르도록 한다.
+표준을 설명하는 문서는 코드 자체로 충분해야 하며 별도 문서를 만들 필요는 없어야 한다.
팀이 정한 표준을 팀원들 모두가 따라야 함.

G25: 매직 숫자는 명명된 상수로 교체하라

ex) 86,400이라는 숫자는 SECONDS_PER_DAY 상수 뒤로 숨긴다.
쪽 당 55줄을 인쇄한다면 숫자 55는 LINES_PER_PAGE 상수 뒤로 숨긴다.
'매직 숫자’라는 용어는 숫자만 의미하지 않음 -> 의미가 분명하지 않은 토큰을 모두 가리킨다.