북클럽 3일차. 2장 의미 있는 이름

의도를 분명히 밝혀라

• 존재 이유는?
• 수행 기능은?
• 사용 방법은?
• 측정하려는 값과 단위를 표현하는 이름
• 코드 맥락이 코드 자체에 명시적으로 드러나야 한다.

그릇된 정보를 피하라

• 의미가 있는 단어를 다른 의미로 사용하면 안된다.
• 흡사한 이름을 사용하지 말자.
• 컨테이너 유형을 이름에 넣지 않는 편이 바람직하다. (List, Map 이런거)
• 유사한 개념은 유사한 표기법을 사용하자.

의미 있게 구분하라

• a1, a2 이딴식으로 구분하지 마라.
• ProductInfo, ProductData 이딴식으로 하지마라.
• 쓸데없는건 넣지 마라. (String, the)
  • 정보를 담고 있어야 된다.
• 예시
  • getActiveAccount()
  • getActiveAccounts()
  • getActiveAccountInfo()

발음하기 쉬운 이름을 사용하라

• 대화나눌때 이름이 걸거치면 피곤해진다.

검색하기 쉬운 이름을 사용하라

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

인코딩을 피해라

• 안그래도 길이가 부족하다.
• 유형이나 범위 정보는 빼자.

• 헝가리식 표기법

  • 옛날에는 타입을 맨앞에 넣어놓을 필요가 있었다.
  • 지금은 특하 자바는 그럴 필요가 없다.

• 멤버 변수 접두어

  • 멤버 변수에 m_ 이런거 완전 별로다.
  • 요즘 IDE는 이런거 붙일 필요가 없다.
  • 구닥다리 코드의 징표

• 인터페이스 클레스와 구현 클래스

  • 인터페이스 클래스와 구현 클래스 이름?
    • IShapeFactory, ShapeFactory 어떤가?
  • 인터페이스 이름은 접두어를 붙이지 않는 편이 좋다고 생각한다.
    • 인터페이스와 구현클래스중 하나에 붙인다고 하면
    • 구현 클래스에 Impl을 붙이겠다.

자신의 기억력을 자랑하지 마라

• a,b,c 이런거
• 반복문에 i, j, k는 허용하겠다.
• 명료함이 최고다.

클래스 이름

• 클래스나 객체 이름은 명사로 하자.
• Manager, Processor, Data, Info 같은 단어는 피하자.

메서드 이름

• 동사로 하자.
• 값 앞에 get, set, is를 붙인다.
  • 접근자(Accessor)
  • 변경자(Mutator)
  • 조건자(Predicate)

기발한 이름은 피하라

• 재미난 이름보다 명료한 이름을 쓰자.
• 장난치지마라 코드에.

한 개념에 한 단어를 사용해라

• fetch, retrieve, get 유사한 용어인데 이랬다 저랬다 하지 마라.
• 좀 비슷한데 유형이 다르면 잘 구분해서 써라.

말장난을 하지 마라

• 한 단어를 두 가지 목적으로 사용하지 마라.
• 맥락이 다르면 이름이 달라야 한다.
• add, insert, append 구분하자.

해법 영역에서 가져온 이름을 사용하라

• 모든 이름을 문제 여역에서 가져오는 정책은 현명하지 못하다.
• 같은 개념을 다른 이름으로 이해하던 동료들이 매번 고객에게 물어야하기 때문이다.
• 기술 개념에는 기술 이름이 가장 적합한 선택이다. (Queue)

문제 영역에서 가져온 이름을 사용하라

• 적절한 프로그래밍 용어가 없다면 문제 영역에서 이름을 가져온다.
• 우수한 프로그래머와 설계자라면 해법 영역과 문제 영역을 구분할 줄 알아야 한다.
• 문제 영역 개념과 관련이 깊은 코드라면 문제 영역에서 이름을 가져와야 한다.

의미 있는 맥락을 추가하라

• 대다수 이름은 스스로 의미가 분명하기 쉽지 않다.
• 클래스, 함수, 네임스페이스에 의미를 넣어 맥락을 부여한다.
• 모든 방법이 실패하면 마지막 수단으로 접두어를 붙인다.
• 변수의 맥락이 전반에서 사용되면 함수를 작은 조각으로 쪼개기
• 같은 의미를 가지는 변수들은 클래스에 같이 담자.

불필요한 맥락을 없애라

• 모든 클래스 이름을 애플리케이션 이름으로 시작하도록 하기. 개똥같은 생각.
• 의미가 분명하면 이름이 짧을수록 좋다.
• 이름에 불필요한 맥락을 추가하지 않도록 주의한다.
  • accountAddress와 customerAddress는 인스턴스로는 좋지만 클래스 명으로는 별로다.
  • Address 는 클래스 이름으로 적합하다.
  • 포트 주소, MAC 주소, 웹 주소를 구분한다면?
    • PostalAddress, MAC, URI 라는 이름도 괜찮다.
    • 모두 Address를 넣을 필요는 없음

마치면서

• 좋은 이름을 선택하는 능력은 교육 문제다.
• 남의 이름도 자유롭게 바꿔주자. 어차피 이름을 외워서 하지 않는다.
• 남의 코드 리팩터링 할 때 이름도 바꿔서 가독성을 개선해보자.