TIL (Today I Learned)

2022.02.20

오늘 읽은 범위

2장. 의미있는 이름

책에서 기억하고 싶은 내용을 써보세요.

• 의도를 분명히 밝혀라 (p.22)

• 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

• 그릇된 정보를 피하라 (p.24)

• 실제 컨테이너가 List인 경우라도 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다.

• 이름으로 그릇된 정보를 제공하는 진짜 끔찍한 예가 소문자 L이나 대문자 O 변수다.

• 의미 있게 구분하라 (p.25)

• 함수 인수 이름으로 source와 destination을 사용한다면 코드 읽기가 훨씬더 쉬워진다.

• 불용어를 추가한 이름 역시 아무런 정보를 제공하지 못한다. ex) ProductInfo, ProductData

• 발음하기 쉬운 이름을 사용하라 (p.27)

• 검색하기 쉬운 이름을 사용하라 (p.28)

• 긴 이름이 짧은 이름보다 좋다. 검색하기 쉬운 이름이 상수보다 좋다.

• 간단한 메서드에서 로컬 변수만 한 문자를 사용한다. 이름 길이는 범위 크기를 비례해야 한다.

• 인코딩을 피하라 (p.29)

• 자신의 기억력을 자랑하지 마라 (p.31)

• r이라는 변수가 호스트와 프로토콜을 제외한 소문자 URL이라는 사실을 언제나 기억한다면 확실히 똑똑한 사람이다.

• 클래스 이름 (p.32)

• 클래스 이름과 객체 이름은 명사나 명사구가 적합하다.

• 동사는 사용하지 않는다

• 메서드 이름 (p.32)

• 동사나 동사구가 적합하다.

• 접근자(Accessor), 변경자(Mutator), 조건자(Predicate)는 javebean 표준에 따라 값 앞에 get, set, is를 붙인다.

• 생성자(Constructor)를 중복정의(overload)할 떄는 정적 팩토리 메서드를 사용한다.

• 생성자 사용을 제한하려면 해당 생성자를 private로 선언한다.

• 기발한 이름은 피하라 (p.32)

• 한 개념에 한 단어를 사용하라 (p.33)

• 말장난을 하지 마라 (p.34)

• 해법 영역에서 가져온 이름을 사용하라 (p.34)

• 전산 용어, 알고리즘 이름, 패턴 이름, 수학 용어 등을 사용해도 괜찮다.

• 모든 이름을 문제 영역(domain)에서 가져오는 정책은 현명하지 못하다.

• 문제 영역에서 가져온 이름을 사용하라 (p.34)

• 의미 있는 맥락을 추가하라 (p.35)

• 불필요한 맥락을 없애라 (p.37)

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 개발하면서 가장 어려운 일은 이름 짓는 일이다.

  
  항상 고민하면서 짓는 편인데 2장을 통해 좀 명확하게 의미있게 이름을 생성할 수 있을 거 같다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• 여러 언어로 프로그래밍하면서 헝가리식 표현법을 쓸 지, 카멜식 표현법을 쓸 지, 그 외의 것을 쓸 지 항상 고민스럽다. 물론 각 언어마다 치우쳐 있긴 하지만 여전히 헷갈린다.